Re: [COSE] Draft IETF 117 COSE agenda

[AJITOMI Daisuke <[e-mail]>]

>
> It's *extremely* unfortunate naming choices, because that's not how JOSE
> works:


...Regarding the KEM/key agreement thing about which we are talking,  *that's
how JOSE works*.

In JOSE, the primary "alg" value for key agreement is "ECDH-ES".
Not only "crv" but also "kty" cannot be determined by the "ECDH-ES".

In the first place, "alg" is just an optional value in JWK/COSE_Key and
cannot be relied upon. There are plenty of examples of JWKS endpoints
without "alg" values.

For example, Azure-AD JWKS endpoints like this...
https://login.microsoftonline.com/common/discovery/keys

Example JWKs in MDN web docs don't use "alg" ...
https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/importKey#json_web_key_import

> And this is "better" than iterating one list of "advertised algorithms"
in the sense that it is "more compact" and "safer" ?

I think the "hkc" approach is better.
- Since it does not rely on "alg", it will work with many existing
implementations and it can be used not only JOSE/COSE but also many other
applications.
- If the recipient(server) wants to support multiple KDF/AEADs for one KEM
algorithm, the "alg" approach should provide multiple KEM keys.
- etc...

--
Daisuke

2023年7月21日(金) 1:53 Orie Steele <[e-mail]>:

> Inline:
>
> On Thu, Jul 20, 2023 at 10:42 AM AJITOMI Daisuke <[e-mail]>
> wrote:
>
>> The point here is... If I tell you -7 (ES256), you know 2 (kty EC2) and 1
>>> (crv P-256)
>>
>>
>> ... No. In COSE, ES256 can be used not only with P-256 but also with
>> other curves (P-521, etc.).
>>
>
> https://datatracker.ietf.org/doc/html/rfc9053#section-8.3
>
> I think you are correct.
>
> It's *extremely* unfortunate naming choices, because that's not how JOSE
> works:
>
> https://datatracker.ietf.org/doc/html/rfc7518#section-3.1
>
> It's also probably not a "good idea" to use "sha256 with P-521" (mismatch
> in hash and curve strength)
> ... Why does COSE encourage this kind of thing, I can't answer that...
>
> It leads to devices needing to support a kitchen sink, or only certain
> protocols, ... it impacts agility.
>
> It seems that COSE created even more flexibility than JOSE, and encouraged
> protocols to lock things down...
> in other words, it punted responsibility, in a way that JOSE did not.
>
>
>>
>> Constrained devices won't ship support for both 6 and 7... so advertising
>>> -8 is therefore ambiguous / not helpful (by itself)
>>
>> ... Now consider advertising "HPKE-Base"... How does this help you know
>>> how to talk to a firmware or relying party?
>>
>>
>> ES256 is also ambiguous... let's use key information.
>>
>
> Seems you are required to use key information to use COSE...
> But not in JOSE... I'm sorta shocked by how bad that is...
> COSE "alg" values are NEVER enough information.
>
> Just for clarity... a receiver needs to advertise a list like this [ kty,
> crv, alg, hkc ].
>
> And then the sender needs to iterate that list to find a match they
> support, in order to send.
>
> And this is "better" than iterating one list of "advertised algorithms" in
> the sense that it is "more compact" and "safer" ?
>
>
>> ... why would we go out of our way to add extra information to this
>>> process, when we are supposed to be trying to design for a compact /
>>> constrained environment?
>>
>>
>> ... The current draft(or "hkc" approach) does not prohibit implementing
>> only a specific combination of KEM/KDF/AEAD for constrained environments,
>> and it is also possible not to put HPKE algorithm information in
>> COSE_Key/JWK as an implicit agreement between a sender and a recipient.
>>
>
> I agree with this.
>
>
>> --
>> Daisuke
>>
>> 2023年7月20日(木) 23:27 Orie Steele <[e-mail]>:
>>
>>> Granted, JOSE & COSE kinda broke this with EdDSA...
>>>
>>> > Therefore, in COSE, even ES256 has to be defined as follows:
>>> >    -7 (ES256), where kty is 2 (with uncompressed points) and crv is 1
>>> (P-256).
>>>
>>> The point here is... If I tell you -7 (ES256), you know 2 (kty EC2) and
>>> 1 (crv P-256)
>>>
>>> If I tell you -8 (EdDSA) .... You know 1 (kty OKP), but *you don't
>>> know if I meant 6 (crv Ed25519) or 7 (crv Ed448)*
>>>
>>> Constrained devices won't ship support for both 6 and 7... so
>>> advertising -8 is therefore ambiguous / not helpful (by itself)
>>>
>>> ... Now consider advertising "HPKE-Base"... How does this help you know
>>> how to talk to a firmware or relying party?
>>>
>>> ... why would we go out of our way to add extra information to this
>>> process, when we are supposed to be trying to design for a compact /
>>> constrained environment?
>>>
>>> OS
>>>
>>>
>>>
>>> On Thu, Jul 20, 2023 at 9:11 AM Michael Prorock <[e-mail]>
>>> wrote:
>>>
>>>> A correction/clarification - basically, while you see both kty and alg
>>>> together, if you have a well defined alg, you always know what kty is for
>>>> that alg - so derivation is from alg alone
>>>>
>>>> Mike Prorock
>>>> CTO - mesur.io
>>>>
>>>> On Thu, Jul 20, 2023, 08:01 Michael Prorock <[e-mail]> wrote:
>>>>
>>>>> Daisuke,
>>>>> definitely 'combination of "alg" and key information.', especially as
>>>>> things have started to evolve recently.  However, I think the point that
>>>>> Orie is trying to make (please correct me if I am wrong Orie) is that once
>>>>> you have the 'kty' which lets you know what shape and family of keys you
>>>>> are dealing with, then you should have everything you need from 'alg' and
>>>>> nothing else.
>>>>>
>>>>> Mike Prorock
>>>>> CTO, Founder
>>>>> https://mesur.io/
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Jul 20, 2023 at 7:53 AM AJITOMI Daisuke <[e-mail]>
>>>>> wrote:
>>>>>
>>>>>> Daisuke asserts “On the other hand, there are no examples like the
>>>>>>> proposal from Hannes/Laurence, where the "alg" value includes information
>>>>>>> about "crv" values and unrelated key operation information (e.g., KDF,
>>>>>>> AEAD)”.  There are actually many such examples.
>>>>>>
>>>>>>
>>>>>> It mainly concerns the latter, which is ”unrelated key operation
>>>>>> information". Anyway, while it is true that JOSE's ES* algs include the
>>>>>> "crv" value implicitly, the COSE's ES* algs don't. The COSE's ES256
>>>>>> algorithm is not limited to P-256 and this crv value and the information
>>>>>> about whether the key is compressed EC point or not ultimately requires
>>>>>> referring to the key info.
>>>>>>
>>>>>> Therefore, in COSE, even ES256 has to be defined as follows:
>>>>>>
>>>>>>    - -7 (ES256), where kty is 2 (with uncompressed points) and crv
>>>>>>    is 1 (P-256).
>>>>>>
>>>>>> It is evident that the mainstream approach is to negotiate using a
>>>>>> combination of "alg" and key information.
>>>>>>
>>>>>> --
>>>>>> Daisuke
>>>>>>
>>>>>>
>>>>>> 2023年7月20日(木) 9:55 Michael Jones <[e-mail]>:
>>>>>>
>>>>>>> [chair hat off]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The interoperability problem caused by polymorphic algorithm
>>>>>>> identifiers is that the “alg” and “enc” values are no longer useful for
>>>>>>> algorithm negotiation.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> In protocols such as OpenID Connect, OAuth 2.0, and WebAuthn/FIDO2, lists of supported “alg” and “enc” values are published in metadata.  For instance, here’s an example from RFC 8414:
>>>>>>>
>>>>>>>     "token_endpoint_auth_signing_alg_values_supported":
>>>>>>>
>>>>>>>         ["RS256", "ES256"],
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The problem with polymorphic algorithm identifiers such as “EdDSA”
>>>>>>> is that they don’t actually specify which algorithm is used.  It could mean
>>>>>>> either “Ed25519” or “Ed448”.  You can’t advertise which you support and/or
>>>>>>> which you want.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> This is a problem in practice for WebAuthn, since some COSE alg
>>>>>>> identifiers are polymorphic and WebAuthn and FIDO2 use COSE algorithm
>>>>>>> identifiers for negotiation.  See that WebAuthn specified that EdDSA always
>>>>>>> uses Ed25519 – making it non-polymorphic but precluding its use with
>>>>>>> Ed448.  Here’s the line doing so at
>>>>>>> https://www.w3.org/TR/webauthn-2/#sctn-public-key-easy:
>>>>>>>
>>>>>>>    - -8 (EdDSA), where crv
>>>>>>>    <https://tools.ietf.org/html/rfc8152#section-13.1.1> is 6
>>>>>>>    (Ed25519).
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Daisuke asserts “On the other hand, there are no examples like the
>>>>>>> proposal from Hannes/Laurence, where the "alg" value includes information
>>>>>>> about "crv" values and unrelated key operation information (e.g., KDF,
>>>>>>> AEAD)”.  There are actually many such examples.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> All the registered JOSE algorithms (for example “ES256”) fully
>>>>>>> specified all parameters until “EdDSA”  was registered.  The COSE
>>>>>>> algorithms from RFC 8812 fully specify all parameters, such as when
>>>>>>> secp256k1 is used and when RSASSA is used.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Likewise, if we had a single HPKE algorithm identifier, it couldn’t
>>>>>>> be used to distinguish which HPKE algorithms are supported (and not all
>>>>>>> will be by all implementations).  This would cause the same problem for
>>>>>>> future systems that, for instance, WebAuthn/FIDO2, OAuth 2.0, and OpenID
>>>>>>> Connect already encounter when polymorphic algorithm identifiers are used.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>                                                        -- Mike
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *From:* AJITOMI Daisuke <[e-mail]>
>>>>>>> *Sent:* Wednesday, July 19, 2023 3:45 PM
>>>>>>> *To:* Michael Jones <[e-mail]>; Ilari Liusvaara <
>>>>>>> [e-mail]>
>>>>>>> *Cc:* cose <[e-mail]>
>>>>>>> *Subject:* Re: [COSE] Draft IETF 117 COSE agenda
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> > Speaking as an individual contributor, I fully support the first
>>>>>>> > (fully specified) choice.  Whereas the second possibility will
>>>>>>> cause
>>>>>>> > endless interoperability problems.
>>>>>>>
>>>>>>>
>>>>>>> I disagree.
>>>>>>>
>>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>> (Below, I comment from the standpoint that the design of alg values
>>>>>>> should be consistent with COSE and JOSE.)
>>>>>>>
>>>>>>> I am convinced that the "fully specified" design, on the contrary,
>>>>>>> includes more interoperability issues.
>>>>>>>
>>>>>>> Originally, in JOSE and COSE, the identification of the specific
>>>>>>> cryptographic algorithm was done by combining the "alg" value ("ECDH-ES,"
>>>>>>> "EdDSA," etc.) with the information held by the key itself ({"kty": "EC",
>>>>>>> "crv": "P-256", ...}, {"kty": "OKP", "crv": "Ed25519", ...}, etc.).
>>>>>>> The current draft follows this approach. On the other hand, there are no
>>>>>>> examples like the proposal from Hannes/Laurence, where the "alg" value
>>>>>>> includes information about "crv" values and unrelated key operation
>>>>>>> information (e.g., KDF, AEAD) to the original key's purpose. In JWK, the
>>>>>>> "alg" value is merely an optional parameter, so packing excessive
>>>>>>> information into the "alg" value will, in fact, lead to interoperability
>>>>>>> issues.
>>>>>>>
>>>>>>> I have repeatedly written about the reasons why the current
>>>>>>> specification is better than the "fully specified" design (*1, *2).
>>>>>>> However, I would like to add one more point from a new perspective.
>>>>>>>
>>>>>>> I am very concerned that JWK, which is a "JSON representation of
>>>>>>> keys" that could be used for a wide range of applications not limited to
>>>>>>> JOSE and COSE, will no longer be available as a means of transmission and
>>>>>>> negotiation of HPKE parameters. I think this is a very big loss.
>>>>>>>
>>>>>>> The following works with no problem with existing JWK
>>>>>>> implementations, and it is also guaranteed to work in the JWK RFC:
>>>>>>>
>>>>>>>   {
>>>>>>>         kty: "EC",
>>>>>>>         crv: "P-256",
>>>>>>>         // alg: "HPKE-v1-Base(-KEM)",   // alg can be omitted as
>>>>>>> many JWKs do
>>>>>>>         hkc: { kem: 0x0010, kdfs: [0x0001], aeads: [0x0001]},
>>>>>>> // Unknown parameters for the JWK implementation MUST be ignored on the JWK
>>>>>>> layer.
>>>>>>>         x: "-eZXC6nV-xgthy8zZMCN8pcYSeE2XfWWqckA2fsxHPc",
>>>>>>>         y: "BGU5soLgsu_y7GN2I3EPUXS9EZ7Sw0qif-V70JtInFI",
>>>>>>>   }
>>>>>>>
>>>>>>> On the other hand, the following does not work with many existing
>>>>>>> JWK implementations. This is because existing JWK implementations often
>>>>>>> throw errors for "alg" values not supported by the bundled JWS/JWE:
>>>>>>>
>>>>>>>   {
>>>>>>>         kty: "EC",
>>>>>>>         crv: "P-256",
>>>>>>>         alg: "
>>>>>>> HPKEv1-Base-DHKEM(P256,HKDFSHA256)-HKDFSHA256-AES128GCM",   // Must be
>>>>>>> specified to specify HPKE parameters if not assuming an offline(implicit)
>>>>>>> agreement.
>>>>>>>         x: "-eZXC6nV-xgthy8zZMCN8pcYSeE2XfWWqckA2fsxHPc",
>>>>>>>         y: "BGU5soLgsu_y7GN2I3EPUXS9EZ7Sw0qif-V70JtInFI",
>>>>>>>   }
>>>>>>>
>>>>>>> I think this example clearly illustrates the harm of putting
>>>>>>> subsequent algorithm information (KDF&AEAD), which is not originally
>>>>>>> relevant to the key itsef, into a key that is originally only used in the
>>>>>>> KEM step.
>>>>>>>
>>>>>>>
>>>>>>> In any case, I am tired of the situation where even after all these
>>>>>>> repeated discussions, even the obvious design point, which is obvious if
>>>>>>> you read the HPKE standard, that "encapsulated_key should be expressed as a
>>>>>>> sequence of bytes," is being rehashed...
>>>>>>>
>>>>>>> I hope the chairs will make a wise decision.
>>>>>>>
>>>>>>> Best regards,
>>>>>>> Daisuke
>>>>>>>
>>>>>>> P.S.
>>>>>>> ... the design of COSE-HPKE was more difficult than I had thought,
>>>>>>> as it required not only knowledge of both COSE and HPKE, but also knowledge
>>>>>>> of JOSE (primarily JWK) in terms of alg value design, and related
>>>>>>> considerations of consistency with the W3C Web Cryptography API and
>>>>>>> existing implementations. So I do not intend to ask you (the mailing list
>>>>>>> participants) to agree with my suggestion easily, but I'm very glad if you
>>>>>>> could read (*1)(*2) without bias.
>>>>>>>
>>>>>>> (*1)
>>>>>>> https://mailarchive.ietf.org/arch/msg/cose/KTpXbZ3UxUH8BuLT4OmhfaToYTk/
>>>>>>> (*2)
>>>>>>> https://mailarchive.ietf.org/arch/msg/cose/cPqYqCagPbWPKwvQODjqn98U3F4/
>>>>>>>
>>>>>>> 2023年7月20日(木) 2:37 lgl island-resort.com <[e-mail]>:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Jul 19, 2023, at 9:52 AM, Michael Jones <
>>>>>>> [e-mail]> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> As a chair, I’d like clarity on what you mean by “the single
>>>>>>> algorithm design”.  Do you mean that each algorithm identifier fully
>>>>>>> specifies all the cryptographic parameters being used?  Or do you mean that
>>>>>>> a single algorithm identifier is used for all the HPKE possibilities?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The proposal that Hannes, Jeremy and a few others favor is roughly
>>>>>>> this. (I picked these three just as an example, the decision we want is not
>>>>>>> whether these three are the ones to register, it is that we will use one
>>>>>>> algorithm ID to indicate the HPKE KEM, KDF and AEAD.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *Alg ID HPKE-P-256 (equivalent to COSE -29 with NIST key)*
>>>>>>>
>>>>>>> KEM: 0x0010 DHKEM(P-256, HKDF-SHA-256)
>>>>>>>
>>>>>>> KDF: 0x0001 HKDF-SHA256
>>>>>>>
>>>>>>> AEAD: 0x0001  AES-128-GCM
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *Alg ID HPKE-P-384 (equivalent to COSE -30 with NIST key)*
>>>>>>>
>>>>>>> KEM: 0x0011 DHKEM(P-384, HKDF-SHA-384)
>>>>>>>
>>>>>>> KDF: 0x0002 HKDF-SHA384
>>>>>>>
>>>>>>> AEAD: 0x0002  AES-256-GCM
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> *Alg ID HPKE-P-521 (equivalent to COSE -31 with NIST key)*
>>>>>>>
>>>>>>> KEM: 0x0012 DHKEM(P-521, HKDF-SHA-512)
>>>>>>>
>>>>>>> KDF: 0x0003 HKDF-SHA512
>>>>>>>
>>>>>>> AEAD: 0x0002  AES-256-GCM
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The one that Ilari and Ajitomi-san favor is what we have now in
>>>>>>> COSE-HPKE:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>    When the alg value is set to 'HPKE-v1-BASE', the HPKE_sender_info
>>>>>>>
>>>>>>>    structure MUST be present in the unprotected header parameter.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>    The CDDL grammar describing the HPKE_sender_info structure is:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>       HPKE_sender_info = [
>>>>>>>
>>>>>>>           kem_id : uint,         ; kem identifier
>>>>>>>
>>>>>>>           kdf_id : uint,         ; kdf identifier
>>>>>>>
>>>>>>>           aead_id : uint,        ; aead identifier
>>>>>>>
>>>>>>>           enc : bstr,            ; encapsulated key
>>>>>>>
>>>>>>>       ]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Speaking as an individual contributor, I fully support the first
>>>>>>> (fully specified) choice.  Whereas the second possibility will cause
>>>>>>> endless interoperability problems.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> We need your efforts primarily has a chair at this point. I think
>>>>>>> we’ve had the discussion.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> LL
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> COSE mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/cose
>>>>>>>
>>>>>>> _______________________________________________
>>>>>> COSE mailing list
>>>>>> [e-mail]
>>>>>> https://www.ietf.org/mailman/listinfo/cose
>>>>>>
>>>>> _______________________________________________
>>>> COSE mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/cose
>>>>
>>>
>>>
>>> --
>>>
>>>
>>> ORIE STEELE
>>> Chief Technology Officer
>>> www.transmute.industries
>>>
>>> <https://transmute.industries>
>>>
>>
>
> --
>
>
> ORIE STEELE
> Chief Technology Officer
> www.transmute.industries
>
> <https://transmute.industries>
>