Re: [COSE] Draft IETF 117 COSE agenda

[AJITOMI Daisuke <[e-mail]>]

>
> 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.).

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.

... 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.

--
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>
>