-
Notifications
You must be signed in to change notification settings - Fork 54
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
Change data structure for signatures to use key IDs as dictionary keys #155
Comments
This is a good idea, it's always nice to make implementation mistakes harder. It might also be worth cross-posting to the sigining-spec project, which is exploring some options for the signature wrapper more generally (cc @adityasaky) Unfortunately, as you mention it would break backwards compatibility. There are a few TAPs in draft stage right now that would also require a major version change, so maybe we can prioritize some of them for a 2.0.0 release? At the very least I think this warrants some discussion (and maybe a community meeting). |
Thanks Marina! Here's how the signing-spec currently defines key IDs. https://github.com/secure-systems-lab/signing-spec/blob/master/protocol.md#signature-definition
As I understand it, it puts the onus on implementations to handle this correctly. I may be mistaken though.
GPG signatures from
Is there one scheduled? Could we also get some thoughts on the current version of signing-spec from folks there? 😄 |
I agree with this (as you can see in python-tuf I'd like to internally handle signatures as a dict for same reasons).
Just checking: I believe you mean for the outermost object to be a dictionary:
|
Correct. I may have made an error in how I edited the structure by hand. |
Because signatures (at least in the preferred ed25519 mode) are deterministic products of the key and payload materials, it doesn't seem like there's a use case for more than one signature from the same key ID.
Meanwhile -- and more concerning -- we've now had two implementations that have mistakenly used vulnerable signature threshold checking that could have been avoided by using a more robust data format that intrinsically prevents this attack.
I'm not sure how to make this change in a way that's both clean and backwards-compatible, but I'd even be satisfied getting this change into the hopper for TUF 2.0, even if that's a ways off.
Old:
New:
I'm assuming there may be future signatures that aren't contained in a single value and therefore can't simply have this structure:
The text was updated successfully, but these errors were encountered: