Orie Steele<https://twitter.com/OR13b> and I have written a new specification creating algorithm identifiers for JOSE and COSE that fully specify the cryptographic operations to be performed - something we'd promised to do during our presentation to the JOSE working group<https://datatracker.ietf.org/meeting/117/materials/slides-117-jose-fully-specified-algorithms-for-jose-and-cose-00> at IETF 117. The introduction to the specification (quoted below) describes why this matters.
The IANA algorithm registries for JOSE [IANA.JOSE.Algorithms<https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms>] and COSE [IANA.COSE.Algorithms<https://www.iana.org/assignments/cose/cose.xhtml#algorithms>] contain two kinds of algorithm identifiers: * Fully Specified: Those that fully determine the cryptographic operations to be performed, including any curve, key derivation function (KDF), hash functions, etc. Examples are RS256 and ES256K in both JOSE and COSE and ES256 in JOSE. * Polymorphic: Those requiring information beyond the algorithm identifier to determine the cryptographic operations to be performed. Such additional information could include the actual key value and a curve that it uses. Examples are EdDSA in both JOSE and COSE and ES256 in COSE. This matters because many protocols negotiate supported operations using only algorithm identifiers. For instance, OAuth Authorization Server Metadata [RFC8414<https://www.rfc-editor.org/rfc/rfc8414.html>] uses negotiation parameters like these (from an example in the specification): "token_endpoint_auth_signing_alg_values_supported": ["RS256", "ES256"] OpenID Connect Discovery [OpenID.Discovery<https://openid.net/specs/openid-connect-discovery-1_0.html>] likewise negotiates supported algorithms using alg and enc values. W3C Web Authentication [WebAuthn<https://www.w3.org/TR/2021/REC-webauthn-2-20210408/>] and FIDO Client to Authenticator Protocol (CTAP) [FIDO2<https://fidoalliance.org/specs/fido-v2.1-ps-20210615/fido-client-to-authenticator-protocol-v2.1-ps-20210615.html>] negotiate using COSE alg numbers. This does not work for polymorphic algorithms. For instance, with EdDSA, you do not know which of the curves Ed25519 and/or Ed448 are supported! This causes real problems in practice. WebAuthn contains this de-facto algorithm definition to work around this problem: -8 (EdDSA), where crv is 6 (Ed25519) This redefines the COSE EdDSA algorithm identifier for the purposes of WebAuthn to restrict it to using the Ed25519 curve - making it non-polymorphic so that algorithm negotiation can succeed, but also effectively eliminating the possibility of using Ed448. Other similar workarounds for polymorphic algorithm identifiers are used in practice. This specification creates fully-specified algorithm identifiers for all registered polymorphic JOSE and COSE algorithms and their parameters, enabling applications to use only fully-specified algorithm identifiers. It furthermore deprecates the practice of registering polymorphic algorithm identifiers. The specification is available at: * https://www.ietf.org/archive/id/draft-jones-jose-fully-specified-algorithms-00.html -- Mike P.S. This note was also published at https://self-issued.info/?p=2401 and was referenced from https://twitter.com/selfissued/status/1696693714008322088.
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
