[jose] Modern Algorithms in the Web Cryptography API IETF 122 followup

[Filip Skokan <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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*