Re: [COSE] Draft IETF 117 COSE agenda

[Michael Prorock <[e-mail]>]

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