Re: [COSE] Draft IETF 117 COSE agenda

[AJITOMI Daisuke <[e-mail]>]

Michael,

It is possible to pack all the information into the alg value.
However, even if it is packed, it still needs to be checked for consistency
with the key information that needs to be verified.
In JOSE ES256, you still need to confirm that the crv value in the key
information is P-256, because the crv value is included in both the alg and
key information. They are duplicated.

Now, the information that Orie and others are trying to put into alg is
unrelated to the role of the key itself.

It should not be in alg. Information about KDF or AEAD is just a hint and
should be defined as a separate key attribute as hint information for
subsequent crypto processing.

--
Daisuke

2023年7月20日(木) 23:02 Michael Prorock <[e-mail]>:

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