On Thu, Jun 01, 2023 at 10:22:55AM -0500, Orie Steele wrote: > I've said this several times before, apologies to the list. > > "alg" has always represented "suites". > > ES256 is sha256 with ecdsa on secp256r1.
In JOSE, not in COSE. > ES256K is sha256 with ecdsa on secp256k1. Yeah, that one is odd in COSE. > ECDH-ES+A128KW on either of those keys indicates ECDH with a specific > KDF that uses sha256 and key wrapping. However, that is always used with bulk encryption algorithm, with no way to restrict that choice. > 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. The way ECDH-ES works is that key determines the group used, an the ECDH-ES "alg" specifies the kdf. Then there may be integrated key wrap step. In JWE, this key wrap step is sometimes required and sometimes forbidden. In COSE, integrated key wrap is size optimization, since nested recipients allow using separate key wrap. > 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.* COSE uses "enc" differently from JWE. Roughly speaking, "enc" maps to "alg" in layer zero, and if there is "alg", it maps to "alg" in layer one. > 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. This is what I think "hkc" and "cbc" are for. "hkc":[[32],[1],[1]], "cbc":[1] Advertises support for "HPKEv1-Base-DHKEM(P256,HKDFSHA256)-HKDFSHA256-AES128GCM" plus AES128GCM for bulk encryption. > 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) I think that is unlikely to be the case. > 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 This is not JOSE. For JOSE, it would be JOSE-HPKE, which must be more complicated than COSE-HPKE, because COSE is just more flexible than JOSE. For example, while COSE-HPKE can do with only one "alg", JOSE-HPKE can not: There must be at least two "alg"s (this is actually related to the required/forbidden key wrap mentioned earlier). And BTW, the latter impiles that using "alg" to restrict keys to HPKE does not work all too well. Fortunately one could define "use":"HPKE". Which is also useful for COSE-HPKE, because no JOSE "alg" value even exists. > 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. This is also how COSE works right now, except "enc" is called "alg" on layer zero. And the current -05 draft does not mention "hkc" at all. And this is the reason for "cbc" ("jbc" for JOSE): To advertise the bulk encryption. > To date, JOSE & COSE keys have supported "alg" values that ONLY cover > "key agreement" or "encryption". Well, for asymmetric JWE/Cose_Encrypt. There are signature, MAC and symmetric encryption keys as well. > 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. > } This is exactly what "jbc"/"cbc" are meant for: "jbc":"A128GCM" (JOSE) "cbc":1 (COSE) > 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. > } If key has "alg": "ECDH-ES+A128KW", then JOSE/COSE specs are very clear that it MUST NOT be used with HPKE. > How do you learn the aead the recipient supports?... It doesn't really > matter. Currently, JOSE/COSE just punt that to the application. The HPKE key format draft contains first attempts at advertising what the recipient supports. However, the mechanisms presented are not sufficient for the purpose. > 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. That is not sufficient to discover the bulk AEAD. One can not assume that every HPKE AEAD is supported as COSE AEAD, or vice versa. The prototype code I wrote works this way: It supports COSE AEAD 2, which can not be used in HPKE. And it allows new HPKE AEAD to appear at any time, but not COSE AEAD. > 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. Historically, the equivalent of kem_id is pulled from the key. > 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. "hkc" is clearly not intended to be used that way. > But that is all poor design, harmful complexity, and needlessly throwing > away convention, all of which degrade security and interoperability. What cose-hpke-05 does today is to have the raw values to stuff into HPKE in the message. What could be simpler? And that is in fact exactly what the protoype code I wrote does. $ cose-hpke-keygen --supported KEM supported: 0010[p256] 0011[p384] 0012[p521] 0020[x25519] 0021[x448] 0030 KDF supported: 0001 0002 0003 AEAD supported: 0001[aes128gcm] 0002[aes256gcm] 0003[chacha20poly1305] Bulk ciphers supported: 1[aes128gcm] 2[aes192gcm] 3[aes256gcm] 24[chacha20poly1305] The names displayed are purely UI concern. Note how KDFs have no name, and how KEM 0030 (post-quantum!) is listed as supported despite having no name (yes, it actually works). > 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. Having implementation look up values to stuff into HPKE from table is certainly not simpler. Especially so if someone gets some "smart" idea and makes something be its own special snowflake. > 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). There is no nice way to refer to arbitrary curve ever invented by cryptographers, while there is a nice way to refer to HPKE algorithms. > 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. What is "the cose use case"? COSE is used across variety of applications on systems ranging from quite constrained to very high-powered. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
