-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
What is secure-systems-lab/signing-spec? #1
Comments
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 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
|
💯 and to you @adityasaky for opening up this discussion.
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.
+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. |
We should consider review the CommunitySpecification and see if we can learn anything from there for signing-spec, TUF and in-toto. |
FYI, I just created a 1.0.0 milestone on the |
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. Is there a better name for this repo?The name is fine for me. How does it relate to
|
They share quite a bit, at least the underlying cryptographic stuff, but also a lot of the metadata formats and schemas. TUF has removed |
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 |
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. |
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. |
Note that we currently use regular JSON as on-disk format. We only canonicalize to generate/verify signatures. |
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. |
@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. |
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. |
Relevant here: in-toto/ITE#13 |
@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. |
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.
More specifically, this project defines:
Out of scope (for now at least?):
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
|
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?
Yes: #16 |
That makes sense to me, @MarkLodato, thanks! We can perhaps expand based on opinions in the PR. |
Great, sent! |
I think we've answered the original questions, and ticketised what we haven't. Let's concentrate discussions in #21... |
TODO: Discuss below questions...
secure-systems-lab/securesystemslib
?securesystemslib
repo?in-toto/in-toto
andtheupdateframework/tuf
?The text was updated successfully, but these errors were encountered: