>
> > 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 <[email protected]>:
>
>
> On Jul 19, 2023, at 9:52 AM, Michael Jones <[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]
> https://www.ietf.org/mailman/listinfo/cose
>
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
