Hi Simo, I filed: https://github.com/cose-wg/draft-ietf-cose-dilithium/issues/17 (to track this discussion)
AKP came from discussions with JOSE & COSE over several a few IETFs where we seemed to agree that PQ keys should be simple, like OKP, but not restricted to a specific crv / building block, whereas OKP makes crv required, AKP makes alg required, and works with any algorithm that can be registered. As much as possible, we should strive for simple, reusable AKP parameters, I don't see why we should need more than: seed, priv, and pub. In a world where only 1 private key format was specified by NIST, we would only have needed priv, and pub. We'll need seed for ML-DSA regardless at this point, the difference will be that we can't reuse these for key type parameters across multiple key types without duplication because of how the registries work. Note that key parameters are key type specific: - https://www.iana.org/assignments/jose/jose.xhtml#web-key-parameters - https://www.iana.org/assignments/cose/cose.xhtml#key-type-parameters You can see that "d" is repeated in these tables for each key type... this would lead to: seed, priv, and pub being repeated for every key type that uses them which we currently think would be: - ML-DSA-44 (seed, priv, pub) - ML-DSA-65 (seed, priv, pub) - ML-DSA-87 (seed, priv, pub) - SLH-DSA-SHA2-128s (priv, pub) - SLH-DSA-SHAKE-128s (priv, pub) - SLH-DSA-SHA2-128f (priv, pub) - ML-KEM (seed, pub) (not sure about this one). - X-WING (seed, pub) Instead of 1 new key type and 3 new key type parameters covering ML-DSA, SLH-DSA, ML-KEM and X-WING for all their registered algorithms. We would have 8 new key types each with at least 2 new parameters registered, leading to at least 16 new registry entries. And the only we get from these extra registrations is the ability to use the same key material It seemed safer, and easier for implementations to support a single new key type with 2 mandatory key type parameters (alg and pub). I prefer not to change our key types at this point. Changing this would impact: - https://datatracker.ietf.org/doc/draft-reddy-cose-jose-pqc-hybrid-hpke <https://datatracker.ietf.org/doc/draft-reddy-cose-jose-pqc-hybrid-hpke/07/> - https://datatracker.ietf.org/doc/draft-ietf-cose-sphincs-plus/ Let's solve the seed issue / pr first, I will apply the naming changes you suggested. If there is still energy to discuss redoing key types, I will leave that to chairs to comment on how they want to proceed. Regards, OS On Fri, Mar 28, 2025 at 6:27 AM Simo Sorce <[email protected]> wrote: > On Thu, 2025-03-27 at 15:26 -0500, Orie wrote: > > Just so I understand, your proposal is that kty should be used to express > > ML-DSA-44, ML-DSA-65 ... ML-KEM-768 ... X-WING and that alg should remain > > optional. > > > > We should then register these key types and any desired algorithms that > are > > supported for each key type. > > alg would still be used to restrict algorithms within a given key type, > but > > the fingerprint for a key would not commit to the algorithm. > > So an ML-DSA-65 and HASH-ML-DSA-65 public key would have the same > > fingerprint. > > > > This is similar to proposals that Ilari and others discussed at the > > beginning of the work. > > Correct. > > -- > Simo Sorce > Distinguished Engineer > RHEL Crypto Team > Red Hat, Inc > >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
