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". 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/>. *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 *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]
