Hi Simo, Filip, Daniel, COSE & JOSE, Inline:
On Thu, Mar 27, 2025 at 8:22 AM 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? > You currently need 2 attributes to determine if a key type might support a given algorithm: kty: EC, crv: P-256 --> alg: ES256 (JOSE) kty: EC, crv: P-256 --> alg: ES256, ES384, ES512, ESP256 (COSE) The point of AKP is to ensure that a key is generated with the intention to support a specific algorithm. If HashML-DSA is specified for JOSE / COSE in the future it would be fine to create a HashML-DSA key: { "kid": "T4xl70S7MT6Zeq6r9V9fPJGVn76wfnXJ21-gyo0Gu6o", "kty": "AKP", "alg": "HASH-ML-DSA-44", "pub": "unH59k4Ru...DZgbTP07e7gEWzw4MFRrndjbDQ", "priv": "129kadu...DZgbTP07e7gEWzw4MFRr54" } > What is the point? > A kty of ML-DSA-XX would work just the same and make integration in > existing software much easier. > Thanks for this feedback. Is your proposal to register a new kty for each ML-DSA parameter set? For example: { "kty": "ML-DSA-44", "alg": "ML-DSA-44", ... } ... { "kty": "ML-DSA-65", "alg": "ML-DSA-65", ... } { "kty": "ML-DSA-65", "alg": "HASH-ML-DSA-65", ... } { "kty": "ML-DSA-65", "alg": "EXTERNAL-MU-ML-DSA-65", ... } ... > 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 ... > Its less misleading in the context of the JWK and COSE RFCs which state: ``` The "alg" (algorithm) parameter identifies the algorithm intended for use with the key. ``` https://datatracker.ietf.org/doc/html/rfc7517#section-4.4 ``` The JWS Signature value is not valid if the "alg" value does not represent a supported algorithm or if there is not a key for use with that algorithm associated with the party that digitally signed or MACed the content. ``` https://datatracker.ietf.org/doc/html/rfc7515#section-4.1.1 Keep in mind that in COSE, alg is optional in both headers and keys, whereas in JOSE alg is mandatory in headers, and optional in keys. ``` This parameter is used to restrict the algorithm that is used with the key. If this parameter is present in the key structure, the application MUST verify that this algorithm matches the algorithm for which the key is being used. If the algorithms do not match, then this key object MUST NOT be used to perform the cryptographic operation. *Note that the same key can be in a different key structure with a different or no algorithm specified; however, this is considered to be a poor security practice.* ``` https://datatracker.ietf.org/doc/html/rfc9052#section-7.1-3.4 Given that 9052 comes after 7517, it would seem that using the same key type (with alg remaining optional) for "ML-DSA-65", "HASH-ML-DSA-65" and "EXTERNAL-MU-ML-DSA-65" would be encouraging a poor security practice (same key *different algorithms*). In the context of JOSE and COSE, one could infer that "in a different key structure" could mean JWK, in which case, I could have a COSE Sign1 that is verifying with a JWK. If the JWK does not have a mandatory algorithm present for ML-DSA, then COSE signatures would have the same security issue as JWS example above, but cross protocol: A COSE Sign1 ("ML-DSA-65", "HASH-ML-DSA-65" and "EXTERNAL-MU-ML-DSA-65") might verify with a JWK that had *no algorithm.* Tackling the design position head on, I consider it a feature of AKP that it cannot easily be used to create keys that work for both "ML-DSA-65" and "HASH-ML-DSA-65". Putting on my attacker hat, I would copy the AKP key, update its algorithm, regenerate its fingerprint if it had one, and then exploit the weaker algorithm. This is the reasoning behind the current design at least from my perspective, although the draft has passed WGLC and is currently in AD Evaluation. > > 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' ? > :) Thanks for this feedback, I will admit that I considered trying to move AKP to SPHINCS-PLUS just to avoid this issue while introducing AKP. ... I still prefer not to do that, despite the frustration regarding seeds and external mu. "priv_exp" is not in https://datatracker.ietf.org/doc/html/draft-ietf-cose-dilithium-05 It's proposed in the branch: https://github.com/cose-wg/draft-ietf-cose-dilithium/pull/16 (this won't be merged if there are objections, can I count this as an objection to merging?) > A seed is not technically a private key, you do not have a full private > key until you expand it. > This is a fair point. I take it your proposal might look like: { "kid": "T4xl70S7MT6Zeq6r9V9fPJGVn76wfnXJ21-gyo0Gu6o", "kty": "AKP", "alg": "ML-DSA-44", "pub": "unH59k4Ru...DZgbTP07e7gEWzw4MFRrndjbDQ", "seed": "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA", "priv": "129kadu...DZgbTP07e7gEWzw4MFRr54" } And for contrast with SPHINCS-PLUS: { "kid": "T4xl7...o0Gu6o", "kty": "AKP", "alg": "SLH-DSA-SHA2-128s", "pub": "unH5...djbDQ", "priv": "129ka...FRr54" } This could be seen as still in keeping with what I believe LAMPs has plans to do, although the draft is not yet updated: https://datatracker.ietf.org/doc/html/draft-ietf-lamps-dilithium-certificates-07#appendix-C.1 I'd like to hear from others if they prefer "seed" + "priv" over "priv" and "priv_exp"... I proposed "priv" as "seed" only to keep with the current -07 framing above. ... these same considerations apply to ML-KEM and X-WING btw... https://datatracker.ietf.org/doc/html/draft-connolly-cfrg-xwing-kem-06#name-test-vectors-todo-replace-w (note seed and sk are the same)... Except that for X-Wing, there is no expanded private key, so we would end up with: { "kty": "AKP", "alg": "ML-DSA-44", "pub": "unH59k4Ru...DZgbTP07e7gEWzw4MFRrndjbDQ", "seed": "AAAA....AAAA", "priv": "129kadu...DZgbTP07e7gEWzw4MFRr54" // actually an expanded private key, but need the seed to validate it } { "kty": "AKP", "alg": "X-WING", "pub": "unH59k4Ru...DZgbTP07e7gEWzw4MFRrndjbDQ", "priv": "AAAAAAAAA....AAAAA", // sk, actually a seed, but expanded to both an x25519 and an ml-kem private key internally. } I will admit that I sorta like the proposal to switch to "seed" + "priv", especially in the context of this thread: https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/gaHWR-Fs3yQ I would note that DJB used the terms "seed" + "expanded", which if we were to do that in JWK, we would end with 3 private information classes for JWKs that use kty: AKP ( seed(ml-dsa), expanded(ml-dsa), priv(slh-dsa, x-wing, ...) ). Note that I asked the pqc-forum, for ML-DSA when "priv_expanded" is present SHOULD / MUST "seed/priv" be present? This is part of why I chose "priv" and "priv_exp", so that multiple algorithms could use the "priv" parameter, and "priv" always represents the minimal information necessary to represent a private key for a given algorithm. Also, no matter which words we use, we will be nudging towards thinking that the seed is or is not the critical private information for the scheme. ... from that perspective I think I prefer the word "priv" for seed (in external interfaces), given that you will always need it to validate the expanded private key(s) > > *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. > : ) See above. I would expect SLH-DSA draft to be updated to say something to the effect of: Note that SLH-DSA does not have a "seed" and similar to CMS, this draft does not specify a pre-hash mode, see https://www.ietf.org/archive/id/draft-ietf-lamps-cms-sphincs-plus-19.html#section-6-2 . I would expect SLH-DSA to use the "priv" parameter (as registered by draft-ietf-cose-dilithium) to represent private information for a given key. > > > > *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 > > _______________________________________________ > COSE mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
