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]
https://www.ietf.org/mailman/listinfo/cose
