CBOR Object Signing and Encryption (COSE) and JSON Object Signing and Encryption (JOSE) Registrations for Web Authentication (WebAuthn) Algorithms
Extracted elements (23)
A new 'ES256K' algorithm identifier was introduced for JOSE because the existing JOSE 'ES256' algorithm is defined to be used only with the P-256 curve, not secp256k1. The COSE treatment of secp256k1 signing is intentionally parallel to JOSE.
RS1 (RSASSA-PKCS1-v1_5 with SHA-1) is registered despite being deprecated because deployed Trusted Platform Modules (TPMs) continue to use it, and WebAuthn implementations need a COSE algorithm identifier for 'RS1' when TPM attestations using this algorithm are being represented.
Whether secp256k1 should be used with ECDH-ES key agreement is explicitly out of scope; the specification only covers ECDSA usage, leaving ECDH-ES applicability to future expert determination.
RSASSA-PKCS1-v1_5 algorithms (RS256, RS384, RS512) are already present in the IANA JOSE algorithms registry; RFC 8812 only adds registrations for the COSE Algorithms registry. This allows interoperability between WebAuthn/CTAP and both COSE and JOSE ecosystems.
A key of size 2048 bits or larger MUST be used with RSASSA-PKCS1-v1_5 algorithms (RS256, RS384, RS512, RS1). Implementations must check that the key type is 'RSA' when creating or verifying a signature.
For JWK secp256k1 keys, the uncompressed point encoding MUST be used, and the 'x' and 'y' values MUST both be exactly 256 bits with any leading zeros preserved.
Implementations SHOULD use a deterministic algorithm to generate the ECDSA nonce k, such as RFC 6979, but SHOULD implement countermeasures where devices are vulnerable to physical fault injection attacks.
New COSE applications and protocols MUST NOT use the RS1 algorithm (RSASSA-PKCS1-v1_5 with SHA-1). It is registered as Deprecated.
The secp256k1 curve MUST be used only with the 'ES256K' algorithm identifier and not with others, including not with the COSE 'ES256' identifier. This applies to both JOSE and COSE contexts.
When verifying or creating an ES256K signature, the 'kty' field MUST be present ('EC' for JOSE or 'EC2' for COSE), the 'crv' field MUST be 'secp256k1', and if 'alg' is present it MUST be 'ES256K'. If 'key_ops' is present, it MUST include 'sign' or 'verify' as appropriate; if JWK 'use' is present it MUST be 'sig'.
The secp256k1 curve is represented in a COSE_Key using 'kty' (1): 'EC2' (2) and 'crv' (-1): 'secp256k1' (8). Either compressed or uncompressed point encodings may be used; the 'x' value MUST be exactly 256 bits with leading zeros preserved.
The secp256k1 curve is represented in a JWK using 'kty': 'EC' and 'crv': 'secp256k1'. The uncompressed point encoding MUST be used for JWK, and both 'x' and 'y' values MUST be exactly 256 bits with leading zeros preserved.
RFC 8812 registers ES256K in the IANA 'JSON Web Signature and Encryption Algorithms' registry (JOSE Implementation Requirements: Optional) for ECDSA using secp256k1 curve and SHA-256.
RFC 8812 registers ES256K (value -47) in the IANA 'COSE Algorithms' registry for ECDSA using the secp256k1 curve and SHA-256. It is marked 'Not Recommended'.
RFC 8812 registers RS256 (value -257), RS384 (-258), RS512 (-259), and RS1 (-65535, Deprecated) in the IANA 'COSE Algorithms' registry for RSASSA-PKCS1-v1_5 using SHA-256, SHA-384, SHA-512, and SHA-1 respectively. All are marked 'Not Recommended' or 'Deprecated'.
RFC 8812 registers secp256k1 in the IANA 'JSON Web Key Elliptic Curve' registry (JOSE Implementation Requirements: Optional) for the SECG secp256k1 curve.
RFC 8812 registers secp256k1 (value 8, Key Type EC2) in the IANA 'COSE Elliptic Curves' registry for the SECG secp256k1 curve, marked 'Not Recommended'.
Care must be taken that a secp256k1 key is not mistaken for a P-256 key, since their representations differ only in the 'crv' value. The only current mitigation is to restrict the set of curves that can be used per algorithm.
Deterministic ECDSA (RFC 6979) is susceptible to fault injection attacks in environments where devices are vulnerable to physical attacks; implementors should evaluate this risk and apply countermeasures or check FIPS certification requirements.
RSASSA-PKCS1-v1_5 with SHA-2 hash functions (RS256, RS384, RS512) inherits the security considerations from RFC 7518 Section 8.3, including exponent restrictions, which is why these algorithms are registered as 'Not Recommended'.
There are theoretical weaknesses with the secp256k1 curve that could result in future attacks; this is the reason it is registered as 'Recommended: No'. Procedures from SEC1, SEC2, and DSS specifications apply.
Timing side-channel attacks are possible if scalar multiplication over secp256k1 does not execute in constant time. Implementations must ensure constant-time operations.
The ES256K signature is a 64-octet value: R and S are each 256-bit unsigned integers serialized as 32-octet big-endian sequences (leading zeros MUST NOT be omitted), concatenated in the order R then S.