ITE-5: Replace signature wrapper with SSL signing spec #13
Conversation
This is in Markdown because that's the format that I know and it's much simpler to edit in. I'll convert to Asciidoc later. Several sections are still empty. They need to be fleshed out before the ITE is accepted.
|
Hi Mark, thank you for putting this up as an ITE! It makes it easier for the community to discuss and evaluate proposals. ITE-5 came up today in an in-toto + TUF discussion on our signature wrapper and our current plan to spin it off into a standalone spec. While this doesn't yet mean this ITE is approved, it received positive feedback. The primary concern is with supporting two formats - we have some legacy clients that will need to continue using the old format, and that'll have to be phased out slowly. We aren't certain we have the bandwidth to maintain implementations for two formats. But apart from that, from the perspective of adopting these into the specification, there are positive signs! |
|
Great, thank you for the update! If there is anything I can do to help, please let me know. (Note: I'll be on leave for the next several weeks but my colleagues will be covering for me.) |
|
Now that I think about it: it's good that payload type is part of each signature, but what happens when sig A claims that the serialized body is type X, but sig B claims that it is type Y? Should payload type be a fixed part of key distribution? Should all keys/sigs be required to have the same payload type for the serialized body? |
|
Hi Trishank, there is only a single Personally, I'd recommend removing multiple signature support altogether. It is a rarely used feature that adds increased complexity and attack surface. Example: go-jose had a vulnerability where it would return "verified" if any of the signatures passed. If multiple signatures are needed, each signer can produce a separate link file. You can always verify that the payloads are identical, if needed. I didn't go so far as to suggest that in this doc, but perhaps I should? |
in-toto produces signatures per functionary separately using different link file per signature. However, TUF shares the same signature format as in-toto, and will be affected by this change. In TUF, we use threshold signatures to require that m out of n roles have signed off on the same metadata payload. TUF does not intrinsically suffer from the same vulnerability as go-jose. What do others think? @JustinCappos @SantiagoTorres |
|
We would value the ability to validate signatures in the PHP-TUF client without a cJSON implementation (or any JSON parsing at all, ideally). Perhaps off-topic for this issue but related to signature modularity, it would also be nice to support FIDO2-style signatures, which could offer a uniquely easy and inexpensive way to enforce offline, hardware-isolated signing. |
The specifics of the signature wrapper were moved to their own repository/effort, in an attempt to better sync goals between TUF and in-toto team members. In turn, we will refer to that spec here, but mention why we are adopting such a spec in ITE-5.
|
Hi everyone. I'm shaking the dust off this ITE. I rephrased things around to check the specifics on signing-spec, rather than here. I also tried to elaborate in our in-toto-specific motivations. Does this look like what you had in mind? |
Co-authored-by: Trishank Karthik Kuppusamy <trishank.kuppusamy@datadoghq.com>
SantiagoTorres
changed the title
Co-authored-by: Aditya Sirish <8928778+adityasaky@users.noreply.github.com>
|
thank you @adityasaky ! |
Thank you @joshuagl! Co-authored-by: Joshua Lock <jlock@vmware.com>
|
It would be helpful to merge the PR so that we can link to ITE-5 without referencing this PR. It seems like there hasn't been any updates or comments in many months. Is anything more needed? Note that it's still Draft Status. |
|
+1, I think there are two small comments and we could merge... |
Envelope is the term used by both SSL Signing Spec as well as the SLSA Attestation Model: https://github.com/slsa-framework/slsa-controls/blob/main/attestations.md
They are defined in the SSL Signing Spec.
These notebooks are no longer relevant to the ITE, now that the details have moved to the signing-spec repo. The reference implementation in this ITE now refers to in-toto itself, and there is not one yet.
Since the message already has its own type indicator, it's better to call them the same thing. Also prefix the URL path with "schemas/".
This ITE is purely about signing-spec.
|
OK, I think all the comments should be resolved now. Please take a look at the latest wording, particularly the psuedocode. Thanks! |
|
Merging now 👍 I'll announce this on the ML soon™ |
This is an initial draft of ITE-5 that defines a new signature scheme. The reasoning is explained in the body. I have already discussed with @SantiagoTorres, who will sponsor this ITE.
Note: This is in Markdown because that's the format that I know and it's much simpler to edit in. We'll convert to Asciidoc before submitting. I'm sending this out now to get initial feedback on the idea.
Several sections are still empty. They need to be fleshed out (or removed) before the ITE is accepted.