Require clients to support new fully-specified COSEAlgorithmIdentifiers

[emlun]

draft-ietf-jose-fully-specified-algorithms has received "IANA OK" and thus seems close to finalized. We should update the defaults, recommended algorithms and examples to use these new identifiers as the COSE algorithm identifiers -7 (ES256) and -8 (EdDSA) are now deprecated ("replacement functionality SHOULD be utilized in new deployments in preference to the deprecated identifier").

Proposed Changes for WebAuthn L3

Moved to:

• Update COSEAlgorithmIdentifier examples and recommendations to prefer fully-specified alg IDs #2282

Proposed Changes for WebAuthn L4

Update requirements on clients to support the new values. Advise RPs that -9 (ESP256) could appear in fido-u2f attestation statements.

• §5.1.3. Create a New Credential - PublicKeyCredential’s [[Create]](origin, options, sameOriginWithAncestors) Internal Method: add -9 (ESP256) before -7 (ES256) in default pubKeyCredParams:

  If pkOptions.pubKeyCredParams’s size
  is zero

  • Append the following pairs of PublicKeyCredentialType and COSEAlgorithmIdentifier values to credTypesAndPubKeyAlgs:
    • public-key and -7 ("ES256").
    • public-key and -257 ("RS256").

• §5.2.1.1. Easily accessing credential data: add -9 (ESP256) and -50 (Ed25519) as required supported algorithms (not for WebAuthn L3, but should be included in L4):

  User agents MUST be able to return a non-null value for getPublicKey() when the credential public key has a COSEAlgorithmIdentifier value of:

  • -7 (ES256), where kty is 2 (with uncompressed points) and crv is 1 (P-256).
  • -257 (RS256).
  • -8 (EdDSA), where crv is 6 (Ed25519).

• §8.6. FIDO U2F Attestation Statement Format signing procedure: add -9 as a possible alg value:

  Signing procedure
  If the credential public key of the attested credential is not of algorithm -7 ("ES256"), stop and return an error.

[selfissued]

Agreed. Per https://datatracker.ietf.org/doc/draft-ietf-jose-fully-specified-algorithms/, the draft will be on the May 8, 2025 IESG telechat. Assuming it's approved then, the draft will proceed to the RFC Editor.

[zacknewman]

Update non-normative examples, and update recommendations for RP to prefer the new values. These are not yet implemented by clients and authenticators, but will gracefully fall back to the legacy values until implemented.

If these identifiers are not implemented by clients and authenticators, then how can you be sure they will "gracefully fall back to the legacy values"? As a Level 3 RP, should I use both IDs "just in case"? For example,

[
  {
    type: public-key,
    alg:-50
  },
  {
    type: public-key,
    alg:-8,
  },
  {
    type: public-key,
    alg:-9,
  },
  {
    type: public-key,
    alg:-7,
  },
  {
    type: public-key,
    alg:-48,
  },
  {
    type: public-key,
    alg:-35,
  },
  {
    type: public-key,
    alg:-257,
  },
]

[emlun]

Yes, my wording was a bit clumsy. I meant it is safe to include for example both -9 (ESP256) and -7 (ES256) in pubKeyCredParams, and authenticators that don't support -9 will simply skip it and "fall back" on -7 (assuming -9 appears before -7, otherwise the -9 option won't be evaluated at all).

So yes, RPs should continue to include the deprecated values in pubKeyCredParams for backward compatibility. Your example is accurate.

[zacknewman]

How will this affect the CBOR encoded payload in the attested credential data? Will the crv key-value pair be dropped seeing how it doesn't provide any information? Specifically will ESP256 be encoded like 1. or 2. below?

1:

{
  1:   2,  ; kty: EC2 key type
  3:  -9,  ; alg: ESP256 signature algorithm
 -1:   1,  ; crv: P-256 curve
 -2:   x,  ; x-coordinate as byte string 32 bytes in length
           ; e.g., in hex: 65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c08551d
 -3:   y   ; y-coordinate as byte string 32 bytes in length
           ; e.g., in hex: 1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd0084d19c
}

2:

{
  1:   2,  ; kty: EC2 key type
  3:  -9,  ; alg: ESP256 signature algorithm
 -2:   x,  ; x-coordinate as byte string 32 bytes in length
           ; e.g., in hex: 65eda5a12577c2bae829437fe338701a10aaa375e1bb5b5de108de439c08551d
 -3:   y   ; y-coordinate as byte string 32 bytes in length
           ; e.g., in hex: 1e52ed75701163f7f9e40ddf9f341b3dc9ba860af7e0ca7ca7e9eecd0084d19c
}

Seeing how CBOR is about being "concise", I'm guessing the latter; otherwise Ed25519 will now be 1 byte larger since -50 takes 2 bytes to encode instead of the one byte needed for -8.

Edit

Ah, the linked draft states:

5. Key Representations

The key representations for the new fully-specified algorithms
defined by this specification are the same as those for the
polymorphic algorithms that they replace, other than the alg value,
if included. For instance, the representation for a key used with
the Ed25519 algorithm is the same as that specified in [RFC8037],
except that the alg value would be Ed25519 rather than EdDSA, if
included.

So the will-be-redundant crv key-value pair will remain.

[emlun]

Indeed. RFC 9053 defines that

For [elliptic curve] public keys, it is REQUIRED that "crv", "x", and "y" be present in the structure. [...]

and the new algorithm identifiers do not change this.

Note that it will be semantically valid for an authenticator to return a public key with alg: -7 (ES256) even when invoked with pubKeyCredParams: [{ alg: -9 (ESP256), ... }]. The key "matches" both the -9 and -7 algorithm identifiers, as you noted, because of the required crv field.

Hm, so we'll probably need to also update the RP ops to account for this:

§7.1. Registering a New Credential
[...]
20. Verify that the "alg" parameter in the credential public key in authData matches the alg attribute of one of the items in pkOptions.pubKeyCredParams.

this step will need to account for the fact that the new fully-specified alg IDs are effectively synonyms of the polymorphic ones in the context of a COSE_Key.

Either that, or we require that authenticators use the same alg value in the COSE_Key as was chosen from pubKeyCredParams.

[zacknewman]

this step will need to account for the fact that the new fully-specified alg IDs are effectively synonyms of the polymorphic ones in the context of a COSE_Key.

Either that, or we require that authenticators use the same alg value in the COSE_Key as was chosen from pubKeyCredParams.

I actually think the alg should be the same. RPs are required to pass the separate COSEAlgorithmIdentifiers which seemingly suggests they are not "that equivalent"; otherwise it would be fine for an RP to pass just one. It seems weird for an RP to only pass the legacy COSEAlgorithmIdentifier—which is allowed per L3 since it's only a recommendation the new COSEAlgorithmIdentifiers are supported—but then receive an attested credential data payload that will be rejected since the RP does not support the new ID. No matter which COSEAlgorithmIdentifier (or both) an RP supports, parsing code will have to support such a value. An RP that supports both will pass both COSEAlgorithmIdentifiers at which point it seems borderline "malicious" for an authenticator to have had the option to choose the correct value from pubKeyCredParams but intentionally choose the different value. If only one COSEAlgorithmIdentifier was passed, then the RP only supports that COSEAlgorithmIdentifier so an authenticator can't use a different one since the RP would not know how to handle it.