What is secure-systems-lab/signing-spec?

[lukpueh]

TODO: Discuss below questions...

• What is the purpose of this repo?
• Is there a better name for this repo?
• How does it relate to secure-systems-lab/securesystemslib?
• .. if so, wouldn't it make more sense to add the signing-spec to the securesystemslib repo?
• How does it relate to in-toto/in-toto and theupdateframework/tuf?
• ...

[adityasaky]

Thanks for setting this up, Lukas! Just filling in some of my thoughts below. :D

---

What is the purpose of this repo?

It depends, I think, on the scope of the new specification. If it's reasonably broad and given to change and grow, then I think the specification can live here rather that in secure-systems-lab/securesystemslib. And either way, it's a good place to have these discussions and identify what parts of the TUF and in-toto specs we can move over.

Is there a better name for this repo?

I'm leaning yes. If we do want to spin this off into its own thing with its own ecosystem, we probably also want a more specific name.

How does it relate to secure-systems-lab/securesystemslib?

At this moment, sslib handles more than what we have in mind with this repo, so this is a good question IMO. Either we maintain sslib as an implementation of this spec with some extras moving forward, or we split it into two libraries (which I think is just more overhead). Is there a third option?

.. if so, wouldn't it make more sense to add the signing-spec to the securesystemslib repo?

See 1.

How does it relate to in-toto/in-toto and theupdateframework/tuf?

At this moment, I'm leaning towards saying both of them refer to this spec as an example of a way to represent and sign their respective metadata. Neither of them enforce a particular format, and both use cJSON for descriptive purposes as per their specs. I think that can be updated to say both use signing-spec / cool-new-name for descriptive purposes in the spec, and the reference implementations don't really see a change in practice.

---

Beyond that, I think we can plan an effort to write this spec using the material in the in-toto and TUF specs. In parallel, we can use this project as a means to handle the other sslib issues that were brought up on the email thread:

• key format inconsistency securesystemslib#251
• Support external signatures (sigs made on system without TUF installed) theupdateframework/python-tuf#1109 - this can be a feature provided by this new spec, and that way we move the conversation out of TUF / in-toto?
• Revise schema and formats facility securesystemslib#183
• Consider not curating a full custom Python code-style guide code-style-guidelines#20
• Update JSON canonicalization (backwards incompatible) securesystemslib#159
• Create public high-level interface for securesystemslib.keys securesystemslib#35
• Remove file system requirements theupdateframework/specification#103 - this one, I think, has already been implemented and requires changing in the TUF and in-toto specs. Again a feature of the new specification rather than TUF / in-toto?

[joshuagl]

Thanks for setting this up, Lukas! Just filling in some of my thoughts below. :D

💯 and to you @adityasaky for opening up this discussion.

What is the purpose of this repo?

It depends, I think, on the scope of the new specification. If it's reasonably broad and given to change and grow, then I think the specification can live here rather that in secure-systems-lab/securesystemslib. And either way, it's a good place to have these discussions and identify what parts of the TUF and in-toto specs we can move over.

I think having the specification in a separate repository to an implementation appears more welcoming of other implementations. It also simplifies maintainability when making releases. Tagging spec releases and implementation releases separately feels necessary but error prone if they share a repo.

How does it relate to secure-systems-lab/securesystemslib?

At this moment, sslib handles more than what we have in mind with this repo, so this is a good question IMO. Either we maintain sslib as an implementation of this spec with some extras moving forward, or we split it into two libraries (which I think is just more overhead). Is there a third option?

+1

I like the idea of having sslib as an implementation of this spec + extras, a separate implementation project feels like maintainer overhead that we don't have the person power to sustain at this time. We could consider splitting into a separate repository at a later date if the circumstances change. We could also consider having sslib provide a pip installable package which includes only what's required to fulfil the spec, with the extras in an additional package.

[joshuagl]

We should consider review the CommunitySpecification and see if we can learn anything from there for signing-spec, TUF and in-toto.

[lukpueh]

FYI, I just created a 1.0.0 milestone on the securesystemslib repo, which is intended to mark the release of the stable signing-spec implementation that we come up with here.

[shibumi]

What is the purpose of this repo?

During my Google Summer of Code internship I got to know in-toto, hence take my next words with a grain of salt.
I spoke with @trishankatdatadog about TUF and in-toto I had sometimes the feeling that in-toto and TUF have a few things in common, but they also differ quite a lot in some other aspects. One example is the keyid_hash_algorithms field in the key specification. In in-toto we have no real use for it, but it seems to be used in TUF. One question I would have is: Does one big specification for both projects even make sense? Furthermore, do does it make sense to use just one specification for two projects? In my opinion, we might have issues with future development... software development is disruptive, just imagine that we want to go with in-toto in a different direction than with TUF. In that specific case

Is there a better name for this repo?

The name is fine for me.

How does it relate to secure-systems-lab/securesystemslib?

securesystemslib has been the base for signing operations and it is de facto the reference implementation for the key specification. I do not know if we should change this fact. You have more experience than me, but I have the feeling we are drifting away from it, because we have more and more implementations in different languages (Rust, Go, etc). Of course a 1-to-1 implementation does not make sense, but this also means that we are reimplementing stuff in other languages again, because they these languages are missing a securesystemslib implementation, like we have for python.

.. if so, wouldn't it make more sense to add the signing-spec to the securesystemslib repo?

I am in favor of splitting documentation and code. This way we can schedule releases for this specification and set a different release version for the libraries/software without confusing users. It is a benefit for us.

How does it relate to in-toto/in-toto and theupdateframework/tuf?

See above.. I think I tried answering this question.

[trishankatdatadog]

I had sometimes the feeling that in-toto and TUF have a few things in common, but they also differ quite a lot in some other aspects. One example is the keyid_hash_algorithms field in the key

They share quite a bit, at least the underlying cryptographic stuff, but also a lot of the metadata formats and schemas. TUF has removed keyid_hash_algorithms which was unfortunate ad-hoc bit that slipped in.

[joshuagl]

How does it relate to in-toto/in-toto and theupdateframework/tuf?

At this moment, I'm leaning towards saying both of them refer to this spec as an example of a way to represent and sign their respective metadata. Neither of them enforce a particular format, and both use cJSON for descriptive purposes as per their specs. I think that can be updated to say both use signing-spec / cool-new-name for descriptive purposes in the spec, and the reference implementations don't really see a change in practice.

Will signing-spec recommend a particular on-disk format? If we are going to recommend canonical JSON we should be sure to choose a well specified canonicalisation scheme like the informational RFC 8785 JSON Canonicalization Scheme (JCS) courtesy of theupdateframework/specification#92

[trishankatdatadog]

Will signing-spec recommend a particular on-disk format?

I don't think we should. I think we should avoid even recommending specifics such as files and metadata formats. Those can be discussed in addendum similar to POUFs.

[shibumi]

Will signing-spec recommend a particular on-disk format?

In In-toto-Go we actually drifted away from the on-disk format, instead we are loading PKCS8 keys. However, I am not biased against providing support for multiple formats, but it should be more like 'plug-ins' instead of making a specific format mandatory.

[lukpueh]

Will signing-spec recommend a particular on-disk format? If we are going to recommend canonical JSON ...

Note that we currently use regular JSON as on-disk format. We only canonicalize to generate/verify signatures.

[joshuagl]

Good catch @lukpueh.

It has been suggested by adopters in the past that it may be desirable to have the wire format match what is verified (explicitly not requiring canonicalization/encoding before checking the signature). Having to canonicalise untrusted data means that implementers need to include the JSON parser/canonicalisation functionality in the TCB.

[shibumi]

@lukpueh @joshuagl what is the outcome of your discussion right now? I am a little bit confused. Do we want to stick with the current on-disk JSON-like format or do we allow other formats? In in-toto-golang we just use plain Keys right now. I would like to know if this is a major deal breaker for the future or if this is fine.

[lukpueh]

When you say, "in-toto-golang we just use plain Keys right now", are you referring to stand-alone private or public keys? Or public keys embedded in in-toto layout metadata? I think only the latter will be formalized in this signing spec.

[adityasaky]

Relevant here: in-toto/ITE#13

[shibumi]

@lukpueh I mean stand-alone keys. Public keys embedded in in-toto layout are a different thing. I still don't like that we treat ed25519 keys special to be honest.

[MarkLodato]

If I may, below are my suggestions. What do you think? If you agree, I'll send a PR to write this in the README.

What is the purpose of this repo?

Simple, foolproof standard for signing arbitrary data.

• Why not JOSE/JWS/JWT? JSON-specific, too complicated, too easy to mess up.
• Why not PASETO? JSON-specific, too opinionated.

More specifically, this project defines:

• Signature protocol
• Data structure for storing the message and signatures
• Suggested crypto primitives (pending Specify revised public key metadata formats #9)

Out of scope (for now at least?):

• Key management / PKI

Is there a better name for this repo?

Yes, IMO this is required. "signing-spec" is too generic. Ideally something easy to search for.

Should we spin the naming question off into a separate GitHub issue?

How does it relate to in-toto/in-toto and theupdateframework/tuf?

Once standardized, those projects can say "sign the message using $NAME". in-toto/ITE#13 does this for in-toto.

[lukpueh]

If I may, below are my suggestions. What do you think? If you agree, I'll send a PR to write this in the README.

Yes, please do! What you wrote below under "What is the purpose of this repo?" and "How does it relate to...?" seems pretty accurate to me. Maybe you can flesh it out just a little bit for the README?

Should we spin the naming question off into a separate GitHub issue?

Yes: #16

[adityasaky]

That makes sense to me, @MarkLodato, thanks! We can perhaps expand based on opinions in the PR.

[MarkLodato]

Great, sent!

[adityasaky]

I think we've answered the original questions, and ticketised what we haven't. Let's concentrate discussions in #21...