Re: [jose] Fully-Specified Algorithms for JOSE and COSE

Interesting considering the pushback I got when I claimed that polymorphic (I used the term overloaded) algorithms wasn't such a great idea, although I was mainly complaining about OKP.

Unfortunately for us implementors this ship has already sailed so in practice we will now have to maintain multiple solutions.

[Somewhat] related: ETSI is a about to take a decision on how to proceed with a JSON-based signature standards proposal building on RFC8785.  Personally, I'm nowadays rather pushing deterministically encoded CBOR which removes the need for canonicalization and is trivial to implement.
https://github.com/cyberphone/cbor-everywhere/tree/main#cryptographic-operations
I believe the myriad of "Wallet" projects out there would benefit by taking a peek at CBOR and enveloped signature solutions.  COSE algorithms and keys still apply.

Anders

On 2023-08-30 3:27, Michael Jones wrote:
> 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 <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 <https://self-issued.info/?p=2401> and was referenced from https://twitter.com/selfissued/status/1696693714008322088 <https://twitter.com/selfissued/status/1696693714008322088>.
> 
> 
> _______________________________________________
> jose mailing list
> jose@ietf.org
> https://www.ietf.org/mailman/listinfo/jose