[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 <[email protected]>
Sent: Wednesday, July 19, 2023 3:45 PM
To: Michael Jones <[email protected]>; Ilari Liusvaara
<[email protected]>
Cc: cose <[email protected]>
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<http://island-resort.com/>
<[email protected]<mailto:[email protected]>>:
On Jul 19, 2023, at 9:52 AM, Michael Jones
<[email protected]<mailto:[email protected]>> 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
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/cose
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
