I hit send too soon... The primary point I was trying to make is: 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 thing we would get from these extra registrations is the ability to use the same key material with no algorithm required to be specified for the key. It seems like a lot of work to enable a poor security practice, which is still possible with AKP, as you noted.
Regards, OS On Fri, Mar 28, 2025 at 10:42 AM Orie <[email protected]> wrote: > 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]
