Re: [COSE] Draft IETF 117 COSE agenda

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