On Thu, Mar 27, 2025 at 03:26:32PM -0500, Orie wrote:

> >
> > Only if "alg" is optional, ie you *can* restrict a key to a specific
> > algorithms but you should not be required to.
> >
> 
> 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.

With ML-DSA, as long as HashML-DSA is not supported, AKP will work just
fine. And using using HashML-DSA is NOT RECOMMENDED:

>From draft-connolly-cfrg-hybrid-sig-considerations:

"Working Groups SHOULD NOT include HashML-DSA as a signature option."


SLH-DSA is more problematic. SLH-DSA does not have any signature-level
tricks like ExternalMu for signing large messages. For this reason, the
above draft has HashSLH-DSA as MAY.

However, I think that COSE and JOSE should sidestep these problems at
protocol level instead of defining HashSLH-DSA. Which would allow using
AKP for SLH-DSA too.


Now, KEMs like ML-KEM-768 and XWING are genuinely beyond what AKP can
deal with, at least for JOSE. The problem is that since algorithms can
not be composed (unlike in COSE) one needs both Direct Key Agreement and
Key Agreement with Key Wrapping modes, which means having at least two
algorithms (even if there is only one supported key wrap). 

(In COSE, one could in theory compose Key Agreement with Key Wrap from
Direct Key Agreement and Key Wrap. In pracice, one would probably want
dedicated algorithm for the combination.)

The proper solution to this is to define OKP "crv" values for the KEM
keys.




-Ilari

_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to