On Thu, Mar 27, 2025 at 09:21:54AM -0400, Simo Sorce wrote: > On Thu, 2025-03-27 at 10:46 +0100, Filip Skokan wrote: > > Dear JOSE WG, COSE WG, and Daniel, > > > > *JWK Key Type - AKP - Algorithm Key Pair* > > This new key type is being defined in draft-ietf-cose-dilithium > > <https://datatracker.ietf.org/doc/draft-ietf-cose-dilithium/>. This key > > type requires that "alg" be always present and uses the "kty" value "AKP". > > Can someone explain what is the point of neutering the menaning of kty, > and requiring two attribute (kty + alg) to determine the key type?
What kty has always meant is what fields does the key have. If one looks at current key types and AKP, one sees that all have different fields. In case of OKP and AKP (without priv_exp), there is no isomorphism because alg is magic in COSE and JOSE but crv is not. > What is the point? > A kty of ML-DSA-XX would work just the same and make integration in > existing software much easier. ML-DSA-44, ML-DSA-65 and ML-DSA-87 keys all have the same fields, and thus by above should be the same kty. > Moreover the use of "alg" sounds misleading as the same ML-DSA-XX keys > can be used already with at least 2 algorithms: ML-DSA and HashML-DSA, > and potentially soon with a "new one" based on external-mu > precomputation ... That is a reason not to register HashML-DSA algorithms. AFAIK, on X.509 side, ML-DSA-XX keys are bound to algorithm, that is, ML-DSA keys can not be used with HashML-DSA (even if this would be sound). "external-mu" is fully compatible with pure ML-DSA. It is literally the exact same computations, just moving some to another module. > > All keys must include a "pub" public key parameter. Private keys in > > addition also include "priv", or "priv_exp", or both where applicable (see > > archive) > > <https://mailarchive.ietf.org/arch/msg/cose/-vIaTIvZoSh21_2vqPakAvzzwSw/>. > > > > If priv is the seed, why not call it just 'seed' ? > A seed is not technically a private key, you do not have a full private > key until you expand it. A bigger problem is what 'seed' and 'expanded' mean with hybrid algorithms. One of the components could be seed and the other expanded (ML-DSA/EdDSA hybrids are especially fun). > > *AES-OCB* > > > > - @Daniel Huigens <[email protected]> the API extension > > specification may request registration similar to how other AES modes > > were > > registered in the original Web Cryptography API spec, that's with > > Algorithm > > Usage Location(s): "JWK" and JOSE Implementation Requirements: Prohibited > > - Can anyone familiar with the original registrations chime in on why > > the JWK-only Usage Location registrations were done as Prohibited? > > - Uses "oct" key type > > To be honest it woud be nice to define typed ktys for different > algorithm types, you definitely never want to use the same keys for > both AES and ChaCha20-Poly1305 encryption anyway, but branding every > secret as a generic "octet" makes it impossible to determine for what > purpose a symmetirc key was created. This is especially problematic if > software wants to back this with an HSM via something like PKCS#11 APIS > where the key type is required and you can't mix key types with > mechanisms (ie you can't use a CKK_AES key with anything but a > CKM_AES_XXX mechanism, so you need to know at the time of creation what > the key is going to be used for). Yes, "oct" is especially problematic case. I think that all "oct" keys need to have "alg" attached. > Note that using "alg" is not what I am after, because "alg" for > something like AES would be exceedingly restrictive in most cases, as > there is no generic "AES" alg, but only specific mode+purpose > algorithms. > for example an AES key used for key wrapping can be used with different > algorithms for wrapping safely. (ie A128KW and PBES2-H256+A128KW and > ECDH-ES+A128KW) One really does not want to mix A128KW and PBES2-H256+A128KW keys (using the latter as former is really bad), and ECDH-ES+A128KW uses totally different kind of key. -Ilari _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
