Hello Simo, your feedback wrt. the AKP key type from draft-ietf-cose-dilithium is best left to its authors to respond to and probably better made in this thread <https://mailarchive.ietf.org/arch/msg/cose/-vIaTIvZoSh21_2vqPakAvzzwSw/> instead, do note that this draft has already been submitted to IESG for publication and is merely getting touch ups to align it with the outcome of the LAMPS WG wrt private key representation. That being said I likewise find the "priv" and "priv_exp" unfortunately named JWK parameters but recognize that it's very late for changes to be suggested on that front.
The registration of new JWK-location only algorithm values for the other algorithms you provided feedback for (AES-OCB and ChaCha20-Poly1305) shouldn't be a cause for concern as it does not interact with actual operations, it's merely a representation topic, not usage. None of the new registration suggestions enable use in JWS or JWE, it's only a JWK representation "alg" value for keys that we do not have a JWS/JWE definition for. The suggestions made follow existing conventions and fit the current registry guidelines. Having the JWK format like so is merely a standardized armor around raw secret import/export operations for the Web Cryptography API. S pozdravem, *Filip Skokan* On Thu, 27 Mar 2025 at 14:21, Simo Sorce <[email protected]> wrote: > 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]
