>
> 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.*
I feel like you're misunderstanding a bit.
The former is "enc(ryption algorithm)" and the latter is "enc(apludated
key)". They are completely different things. And the latter doesn't
appear as a top-level attribute.
> 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 "alg" value you refer to as ciphersuites has traditionally remained
within the range of operations expressed by the "key_ops" value. For
example, the key_ops value for "EdDSA" is "sign/verify," while for
"ECDH-ES+A128KW," it is "deriveKey," and for "A128GCM," it is
"encrypt/decrypt".
Your proposal deviates from this rule. If the alg value is
"HPKEv1-Base-DHKEM(P256,HKDFSHA256)-HKDFSHA256-AES128GCM", I feel that the
"key_ops" value should appropriately be "encrypt/decrypt".
However, the purpose of the key is KEM, so the key_ops should include
"deriveBits". If it doesn't, it may not work correctly on web browsers. It
is because the HPKE KEM operation internally needs to call the deriveBits()
with a CryptoKey object as an argument, if the key_ops attribute is present
in the CryptoKey, it must include the value "deriveBits".
In summary, it seems that your proposal goes against established COSE
conventions and lacks compatibility with the Web Crypto API in web browsers
(although I haven't checked it).
> Yes, I think "alg" should work the way it has previously worked, for both
keys and envelopes.
It looks to me that your "alg" system is different from the way it has
previously worked. At least, there is a sense of discomfort in the
relationship between "alg" and "key_ops". It feels strange.
> I don't think a new "alg" system should be invented in COSE-HPKE.
and it is also a new "alg" system from my point of view.
I apologize, but I don't see any specific advantages in your proposal
compared to the current draft.
Daisuke
2023年6月2日(金) 0:23 Orie Steele <[email protected]>:
> 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
>
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
