On Thu, 2025-03-27 at 10:46 +0100, Filip Skokan wrote: > Dear JOSE WG, COSE WG, and Daniel, > > (draft-ietf-cose-sphincs-plus > <https://datatracker.ietf.org/doc/draft-ietf-cose-sphincs-plus/> and > draft-ietf-jose-pqc-kem > <https://datatracker.ietf.org/doc/draft-ietf-jose-pqc-kem/> authors, please > note there's feedback towards your drafts in this message as well). > > As promised in the IETF 122 JOSE WG meeting where I've presented the topic. > Having digested the discussion that occurred, here's the promised follow up > feedback to the upcoming extension to the Web Cryptography API with my > recommendations to its author/editor, a heads up for the COSE and JOSE > Working Groups, as well as feedback towards some of the WG drafts. > > The Web Cryptography API <https://w3c.github.io/webcrypto/> (javascript > cryptography interface available in most javascript runtimes) is about to > have its second extension proposed to the Web Platform Community > Group. This specification defines a number of modern cryptographic > algorithms for the Web Cryptography API, currently that's ML-KEM, ML-DSA, > SLH-DSA, AES-OCB, ChaCha20-Poly1305, SHA-3, cSHAKE, KMAC, and Argon2. > > The APIs intersection with the JOSE WG is the JSON Web Key format used for > key import/export operations. This brings the COSE WG draft into the > discussion because for some of the algorithms the new JWK Key Type and > algorithms are being defined in COSE WG drafts. > > Here are my suggestions for Daniel, the extension's author and the API's > current editor, regarding the current algorithms in the draft's scope. > > *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 is the point? A kty of ML-DSA-XX would work just the same and make integration in existing software much easier. 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 ... > 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. > *ML-DSA* > > - uses AKP > - "alg" values are being defined in draft-ietf-cose-dilithium > <https://datatracker.ietf.org/doc/draft-ietf-cose-dilithium/> > - "priv" is the seed > - "priv_exp" is the expanded private key > - when both "priv" and "priv_exp" are present during import then "priv" > must expand to "priv_exp" > - @Daniel Huigens <[email protected]> the above is fully > supporting the API's JWK import/export operations. > > *ML-KEM* > > - feedback to draft-ietf-jose-pqc-kem > <https://datatracker.ietf.org/doc/draft-ietf-jose-pqc-kem/> authors: The > draft currently does mention key representations. My assumption is that the > AKP key type is to be used and to support that the draft needs to > explicitly mention doing so and explain how the AKP Key Parameters are to > be used. > - @Daniel Huigens <[email protected]> assuming ML-KEM JWK keys > will be represented the same as ML-DSA this is fully supporting the API's > JWK import/export operations. > > *SLH-DSA* > > - worked on in draft-ietf-cose-sphincs-plus > <https://datatracker.ietf.org/doc/draft-ietf-cose-sphincs-plus/> > - SLH-DSA-SHA2-128s, SLH-DSA-SHAKE-128s, and SLH-DSA-SHA2-128f alg > values are defined in the draft > - @Daniel Huigens <[email protected]> for parameter sets not > planned to be registered by the COSE WG draft the API extension > specification may request registration similar to how RSA-OAEP-384 was > registered in the original Web Cryptography API spec, that's with Algorithm > Usage Location(s): "alg" and JOSE Implementation Requirements: Optional > - feedback to draft-ietf-cose-sphincs-plus > <https://datatracker.ietf.org/doc/draft-ietf-cose-sphincs-plus/> authors: > The draft currently mentions key representations to use the AKP type but > does not explicitly mention what "priv" and "priv_exp" parameters > represent, while I think this is very much clear it would be prudent for > your draft to expand on the topic similar to how cose-dilithium does or how > cose-sphincs-plus hopefully will in its future revisions. > > *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). 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) And the key could be generate via derivation operation that does not know exactly which AES operation will the key be used for... > *ChaCha20-Poly1305* > > - @Daniel Huigens <[email protected]> same as AES-OCB, note that > the value "C20P" was previously used in an I-D > <https://datatracker.ietf.org/doc/draft-amringer-jose-chacha/> and some > libraries implement it, you may consider registering that value > - Uses "oct" key type > > *SHA-3 and cSHAKE* > > - These Web Cryptography Algorithms interact with other algorithms that > specify a hash as part of either its CryptoKey algorithm or the operation's > algorithm (HMAC, RSASSA-PKCS1-v1_5, RSASSA-PSS, ECDSA, RSA-OAEP > - In the past JWK registrations were done for HS1, RS1, and PS1 > - @Daniel Huigens <[email protected]> much like HS1, RS1, and PS1 > I believe a registering every combination of the new digest algorithms with > existing hash-based algorithms is impractical (and would not find any use > outside of the API itself similar to its past HS1, RS1 and PS1 > registrations). Therefore I recommend that either the API support JWK > import/export of such keys but > - during JWK import the "alg" member must not be present > - during JWK export the "alg" member is omitted; > - - or - > - the API only supports non-JWK export/import key formats when the > new digest algorithms are present on the key algorithm. > > *KMAC* > > - @Daniel Huigens <[email protected]> given the updated guidance > on registrations in the JSON Web Signature and Encryption Algorithms IANA > registry we would not be able to register the algorithms for KMAC128 and > KMAC256 unless they also implied an empty customization (S input parameter) > member and a fixed length (L input parameter) members. As such I recommend > that either the API support JWK import/export of such keys using the "oct" > key type but > - during JWK import the "alg" member must not be present > - during JWK export the "alg" member is omitted; > - - or - > - the API only supports non-JWK export/import key formats for the > KMAC algorithm > > *Argon2* > > - has no interaction with JWK :check: > > > S pozdravem, > *Filip Skokan* > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] -- Simo Sorce Distinguished Engineer RHEL Crypto Team Red Hat, Inc _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
