I've said this several times before, apologies to the list. "alg" has always represented "suites".
ES256 is sha256 with ecdsa on secp256r1. ES256K is sha256 with ecdsa on secp256k1. ECDH-ES+A128KW on either of those keys indicates ECDH with a specific KDF that uses sha256 and key wrapping. AFAIK, the first occurrence of "alg" comes from https://www.rfc-editor.org/rfc/rfc7517#section-4.4 >From the beginning, these "alg" values encapsulated complexity for developers, most commonly by setting the hash function used before ECDSA, or the kdf used after ECDH. AFAIK, the first occurrence of "enc" comes from https://www.rfc-editor.org/rfc/rfc7516.html#section-4.1.2 Note that COSE-HPKE use "enc" differently, and instead of *identifying an aead algorithm*, it represents the output of the kem, in the case of dh kems, that is a *public key as opaque bytes.* See https://datatracker.ietf.org/doc/html/draft-ietf-cose-hpke-05#section-4.2 JOSE and COSE seem to have not aligned on use of "enc" : - https://www.iana.org/assignments/jose/jose.xhtml - https://www.iana.org/assignments/cose/cose.xhtml Consider also the interaction with: - https://datatracker.ietf.org/doc/html/rfc9053#section-4.1 Let's look at a simple example: Your closest friend only supports "HPKEv1-Base-DHKEM(P256,HKDFSHA256)-HKDFSHA256-AES128GCM". You start with the recipient public key, if it contains alg, you use it, if it does not, you somehow learn that the recipient supports the above suite, maybe ask them if they have an iPhone. You prepare their message, as you normally would with HPKE. You put the message in an envelope that makes it easy for the recipient to safely handle it. The minimum information needed for the envelope is: [ kem_id, kdf_id, aead_id ] ... all of these can be omitted from an envelope IF they are discoverable from a key representation (such as JWK or COSE Key) If you wanted to align with JOSE, you would just do [ kem_id, kdf_id ] and send the aead, in the envelope. https://www.rfc-editor.org/rfc/rfc7516.html#appendix-A.1.1 Excluding aead from the key agreement algorithm does make some sense, but then you end up with what JOSE has, where you need to learn the aead that is supported some other way... worth noting the current -05 draft combines "aead with key agreement", by telling you certain "alg" values are dependent on certain "hkc" values. To date, JOSE & COSE keys have supported "alg" values that ONLY cover "key agreement" or "encryption". But you can imagine wanting to build an API that took a JOSE or COSE Key for "Key Agreement", and produced a Key for "Encryption". If the first key contained an aead in its "algorithm" the second key's algorithm would use that same aead. "alg" is always optional, but it can be used to create easier to understand, and safer to use APIs. JOSE / COSE today: { "kty": "EC", "crv": "P-256", "x": "z0JJ6bYOwvIXL0RlE-0iOUUAQ1KWz2YpPvVLXY2ah-4", "y": "eXLXYE-rH71FtvWihfOclbcSFNMRMGGDej7X8tc5_s8", "alg": "ECDH-ES+A128KW" } ==> { "kty":"oct", "k":"GawgguFyGrWKav7AX4VKUg", "alg": "A128GCM", // how do you know if the recipient above supports this?... you learned without looking at their key. } JOSE / COSE tomorrow: { "kty": "EC", "crv": "P-256", "x": "z0JJ6bYOwvIXL0RlE-0iOUUAQ1KWz2YpPvVLXY2ah-4", "y": "eXLXYE-rH71FtvWihfOclbcSFNMRMGGDej7X8tc5_s8", "alg": "ECDH-ES+A128KW (*+A128GCM) *" ~~~= "HPKEv1-Base-DHKEM(P256,HKDFSHA256)-HKDFSHA256-AES128GCM" } ==> { "kty":"oct", "k":"GawgguFyGrWKav7AX4VKUg", "alg": "A128GCM", // now you know where this came from... you learned it when you learned their key agreement key. } The example above applies to both JOSE and COSE, see https://datatracker.ietf.org/doc/html/rfc9052#appendix-B How do you learn the aead the recipient supports?... It doesn't really matter. cbor can easily handle structuring of aead, "enc" or "ciphertext", see https://datatracker.ietf.org/doc/html/draft-ietf-cose-hpke-05#section-5.1 The point is the "alg" value either helps you learn or it doesn't, and since "alg" is always optional, you can't rely on it 100% of the time. But you should be able to rely on "alg" behaving how it has in the past, and providing the same safety features it has in the past. At a minimum this means communicating the kem_id and kdf_id. We can of course invent a "new way" of doing this.... where "alg" and "hkc" work together to accomplish what a single "integer" or a "string" could have, or what 2 strings in JOSE do today, or what an array does in cose-hpke-05 today. But that is all poor design, harmful complexity, and needlessly throwing away convention, all of which degrade security and interoperability. I'm not saying I know for sure what the "value" side of "alg" should be for HPKE COSE Keys or Envelopes, but I know we don't need new parameters for either case, we just need to pick "alg" values that people want to use and register them. Arguing that we must register everything that is in the HPKE registry, is similar to arguing that we must register every curve ever invented by cryptographers in the JOSE / COSE registry, it would be bad for developers to suggest they should support every option cryptographers have registered (HPKE is a CFRG established registry). Similarly, arguing we should use a CFRG registry and support 100% of it for COSE, without any expert review *applied to the cose use case*, is also a bad idea. COSE registry has experts focused on key parameters, they are: Francesca Palombini, Carsten Bormann COSE registry has experts focused on algorithms, they are: Göran Selander, Derek Atkins, Sean Turner. We get better interoperability & security in COSE by handling this in the simplest manner that aligns with the conventions we have had to date. OS On Thu, Jun 1, 2023 at 4:52 AM Carsten Bormann <[email protected]> wrote: > On 2023-06-01, at 11:07, John Mattsson <john.mattsson= > [email protected]> wrote: > > > > I don’t think COSE in the past had something that can be described as > cipher suites. > > To me anything that has a “w/” or a “+” (mostly) in > https://www.iana.org/assignments/cose/cose.xhtml#algorithms > is a cipher suite. > Sorry if that term is not rigorously defined... > > Grüße, Carsten > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
