ML-DSA signing scheme for TUF metadata#195
ML-DSA signing scheme for TUF metadata#195kommendorkapten wants to merge 4 commits intotheupdateframework:masterfrom
Conversation
Signed-off-by: Fredrik Skogman <kommendorkapten@github.com>
kommendorkapten
changed the title
| limitations on message size, and potential interface constraints that | ||
| make pure mode ML-DSA unsuitable for some TUF deployments. | ||
|
|
||
| # Specification |
There was a problem hiding this comment.
I was a bit confused until I got to the "TUF metadata parameters" section about where this fit with TUF. Maybe you could move that sub-section earlier
| ``` | ||
| 0x74 || 0x75 || 0x66 || version || H(MSG) | ||
| ``` | ||
| 5. Sign the pre-signing byte string using an empty context |
There was a problem hiding this comment.
Does it make sense for us to include advice around where to do the signing? (Like do we suggest using a hardware device?) I'm not sure if this makes sense to include, but maybe we can include a link or something to guide implementers in the right direction
There was a problem hiding this comment.
I think this should be out of scope for the TAP, as the decision to use an HSM vs SK vs KMS vs raw key is based on the integrating project's threat model.
Maybe as a separate TAP if this guidance doesn't exist?
There was a problem hiding this comment.
I think we need to sit tight here on any recommendation. I immediately see two different paths in the future:
- Root signing like Sigstore does: HSMs, like YubiKey (assuming they release one soon that supports ML-DSA)
- KMS for online signing of eg. targets.
So I think this TAP benefits from just defining the signing scheme.
mnm678
left a comment
mnm678
left a comment
There was a problem hiding this comment.
I left a few minor comments, but overall I think this is a great scheme, and addresses some of the performance concerns around ML-DSA
| 0x74 || 0x75 || 0x66 || <version> || H(MSG) | ||
| ``` | ||
|
|
||
| The domain separators are the ASCII codes for `tuf`. |
| ## Signature generation | ||
|
|
||
| 1. Load the public key from TUF metadata | ||
| 2. Parse the version from the public key's `scheme` and prepare the |
There was a problem hiding this comment.
We could change H to SHA-512 since it's fixed? I think this was from an earlier revision when H was variable.
There was a problem hiding this comment.
My thinking of keeping it is that we still have the hash decided per the version of the protocol. But you are right that for v1 only SHA-512 is allowed. For keeping the spec generic of the version I think it makes sense to keep it as is.
| ``` | ||
| 0x74 || 0x75 || 0x66 || version || H(MSG) | ||
| ``` | ||
| 5. Sign the pre-signing byte string using an empty context |
There was a problem hiding this comment.
I think this should be out of scope for the TAP, as the decision to use an HSM vs SK vs KMS vs raw key is based on the integrating project's threat model.
Maybe as a separate TAP if this guidance doesn't exist?
| * Version byte: `0x01` | ||
| * Hash algorithm: SHA-512 | ||
| * Implementations MUST support | ||
| * `ML-DSA-44` |
There was a problem hiding this comment.
Should we explicitly state the valid KEYTYPEs and SCHEMEs? All lower case to match https://theupdateframework.github.io/specification/latest/#file-formats-keys or upper case?
There was a problem hiding this comment.
ah you do below...maybe that should be higher?
There was a problem hiding this comment.
Yes, @mnm678 had a few similar comments to I'll shuffle things around so more TUF details are in the beginning, I think that will make it easier to read.
| 2. Load up the public key for verification | ||
| 3. Parse `scheme` into parameter set and version | ||
| * Reject if the protocol version is not supported | ||
| * Implementations MUST NOT infer or select an ML-DSA |
There was a problem hiding this comment.
Should implementations verify the length of the public key and/or signature based on the ML-DSA parameter set? Maybe this is already handled by the underlying library?
There was a problem hiding this comment.
That should be managed by the underlying library, and I rather not see any TUF related code try to delve into analyzing the signature/pk size. I clarify this.
Signed-off-by: Fredrik Skogman <kommendorkapten@github.com>
Signed-off-by: Fredrik Skogman <kommendorkapten@github.com>
Signed-off-by: Fredrik Skogman <kommendorkapten@github.com>
|
Thanks for the feedback ❤️ |
3 participants
Wrote up a TAP on how to encode ML-DSA keys when used within TUF and added a section on pre-auth encoding as certain targets can be fairly larger, and ML-DSA operates in pure mode, that is, no pre-hashing which is the case for RSA and ECDSA.