[jose] Re: Algorithm identifiers for ML-KEM and ML-DSA

[Ilari Liusvaara <[e-mail]>]

On Tue, Aug 20, 2024 at 03:02:07PM -0500, Orie Steele wrote:
> On Tue, Aug 20, 2024 at 2:31 PM Ilari Liusvaara <[e-mail]>
> wrote:
> 
> > On Tue, Aug 20, 2024 at 01:48:41PM -0500, Orie Steele wrote:
> > >
> > >
> > > Current ML-DSA proposal:
> > >
> > >
> > https://datatracker.ietf.org/doc/html/draft-ietf-cose-dilithium-03#name-the-ml-dsa-algorithm-family
> >
> > As note, there is potential for some confusion in "ML-DSA Algorithm
> > Family".
> >
> > JWK refers to "cryptographic algorithm family", but the meaning is
> > rather different, being defined by kind of key used rather than any
> > algorithmic similarity. ML-DSA belongs to much larger "cryptographic
> > algorithm family", which includes things like SLH-DSA and FALCON. It
> > would also include suitably defined pre-quantum algorithms.
> >
> >
> The use of the term is intentionally aligned:
> 
> https://datatracker.ietf.org/doc/html/rfc7517#section-4.1
> https://datatracker.ietf.org/doc/html/draft-ietf-cose-dilithium-03#name-the-ml-dsa-key-type
> https://datatracker.ietf.org/doc/html/draft-ietf-cose-dilithium-03#appendix-A.1.1

I think the wording in RFC7517 section 4.1 is really horrible.

What "kty" is actually meant for is specifying what other parameters
exist, and their types and meanings (e.g., from what registry, how
does this map to cryptographic algorithm input?)

With legacy stuff like RSA or generic ECC, this does indeed map into
sets of related cryptographic algorithms, because the decomposed
components vary among non-related algorithms (e.g., e makes sense in
RSA, but not generic ECC, and vice versa for y).

Modern stuff (e.g., X*, EdDSA, ML-KEM, ML-DSA, SLH-DSA) all use byte
strings for keys (important advance!), leaving only how subtyping is
done to affect key type.

AFAICT, there are three sensible ways to subtype modern stuff:

- By alg the key is for (currently no defined kty)
- By JOSE registry of key subtypes (this is OKP).
- By other registry of key subtypes, one kty per registry (currently
  there are none).

(Then there is the stateful hash signatures that are special case
because those don't have private keys in classical sense.)

One can get hint of this by considering that all symmetric stuff uses
"OCT", despite the wildly different algorithms (this does get annoying
with keys that do not have alg).


> I think you are arguing that "kty" : "ML-DSA" should be "kty: "PQK", so
> that both ML-DSA and SLH-DSA can use the same kty, just with different
> algorithms.

No, I am arguing that all keys that are:

- Subtyped using "alg"
- Public key is byte string.
- Private key is byte string.

Should have the same kty regardless of if those are pre-quantum or
post-quantum, what cryptographic algorithm is used, etc...

This corresponds to the first part in "ways to subtype" above.

Earlier I proposed name "AKP" (Algorithm Key Pair) for such key type.


And really the only thing in JOSE such keys are suitable for is non-
prehashed signatures.


> ... see:
> https://datatracker.ietf.org/doc/html/draft-ietf-cose-sphincs-plus-04#appendix-A.1.1
> ... and then we add some "crv" like property to tell ML-DSA and SLH-DSA
> apart, like we do for kty OKP and kty EC...

Similarly, all keys that are:

- Subtyped from JOSE registry other than alg.
- Public key is byte string.
- Private key is byte string.

Should have kty OKP regardless of if those are pre-quantum or
post-quantum, what cryptographic algorithm is used, etc...

This is the second part in "ways to subtype" above.


(Earlier, there was proposed "HPKE" key type, that did not break the
above rule because it subtypes using HPKE KEM registry, not JOSE
registry. This is the third part of "ways to subtype" above.)




-Ilari