Hi Ilari, The link to https://github.com/cose-wg/HPKE/blob/main/draft-ietf-cose-hpke.txt points to the earlier draft. The new text is in the PR.
The approach that is documented in the PR (see https://github.com/cose-wg/HPKE/blob/9914fa6f84b28046ee29762551798760dbaa3b7f/draft-ietf-cose-hpke.md) aligns with what is done with public key encryption in the COSE RFC but the text has not been updated in the PRs because the discussion focused on something else. Ciao Hannes -----Original Message----- From: COSE <[email protected]> On Behalf Of Ilari Liusvaara Sent: Monday, January 16, 2023 4:48 PM To: [email protected] Subject: Re: [COSE] COSE-HPKE: Moving Forward On Mon, Jan 16, 2023 at 10:59:09AM +0000, Hannes Tschofenig wrote: > Any comments from your side, Ilari? > > From: COSE <[email protected]> On Behalf Of Hannes Tschofenig > Sent: Wednesday, January 11, 2023 12:52 PM > To: [email protected] > Subject: [COSE] COSE-HPKE: Moving Forward > > Hi all, > > To move forward with the COSE-HPKE draft two open issues need to be > addressed. I posted a mail in December, see > https://mailarchive.ietf.org/arch/msg/cose/Cv-UumRRmmXWzrDHAhOAk0iV6fI > / I took a look at https://github.com/cose-wg/HPKE/blob/main/draft-ietf-cose-hpke.txt, and I seems to contain other issues that I thought were already resolved. Specifically, centered along the "info" and "aad" parameters: It contains statements "This specification does not mandate the use of the info and the aad parameters." and "The content of the info parameter is based on the 'COSE_KDF_Context' structure, which is detailed in Figure 3." Are those two statements even consistent with one another? And more seriously: - Content of "aad" and "info" is interop-critical: Two implementations will not interoperate if they do not agree on "aad" and "info". - What is the KeyDataLength of COSE_KDF_Context supposed to be for single-layer (the value is completely meaningless)? Zero? - The AlgorithmID of COSE_KDF_Context seems to be defined as inner algorithm, instead of outer algorithm. This is useless for single- layer and unsound for two-layer. - Despite HPKE being AEAD-capable, it does not follow how RFC 9052 specifies AEAD algorithm should be used (section 5.3.) without any obvious technical reason. Specifically, RFC 9052 says aad is Enc_structure. > The two open issues (IMHO) are: > > > 1. Should we make the kem_id in the encapsulated_key structure > mandatory, as Laurence suggested. Well, mandatory kem_id is two byte penalty, but avoids what looks like annoying spec work and a bit of implementation complexity, so I think it is midly on side of being worthwhile to make mandatory. > 2. Should we avoiding the polymorphic approach for the > encapsulated_key registration, as Daisuke suggested. Well, I suppose registering concrete non-extensible structure can be done if it is unlikely that whatever needs to extend it is worth one- byte identifier. There are quite few one byte identifiers, but many more two-byte ones (let alone longer than that). > To make it easier to understand these two issues, let me point you the > current version of the PR: > https://github.com/cose-wg/HPKE/blob/9914fa6f84b28046ee29762551798760d > baa3b7f/draft-ietf-cose-hpke.md > > Regarding issue#1, we are talking about changing the encapsulated_key > structure > > from > > encapsulated_key = [ > kdf_id : uint, ; kdf id > aead_id : uint, ; aead id > enc : bstr, ; enc > ? kem_id : uint, ; kem id > ] > > to: > > encapsulated_key = [ > kdf_id : uint, ; kdf id > aead_id : uint, ; aead id > kem_id : uint, ; kem id > enc : bstr, ; enc > ] Bikeshed: I would put those in order kem_id, kdf_id, aead_id, enc. > > Regarding issue#2, the change relates to how the encapsulated_key structure > is registered in the COSE IANA registry (under COSE header parameters). > > Change from: > > * Name: encapsulated_key > * Label: TBD2 (Assumed: -4) > * Value type: bstr / [any] / { any => any } > * Value Registry: N/A > * Description: Encapsulated key for KEM-like algorithms > To: > > * Name: encapsulated_key > * Label: TBD2 (Assumed: -4) > * Value type: Array > * Value Registry: N/A > * Description: Encapsulated key for KEM-like algorithms Having "array", as opposed to some concrete (encapsulated_key?) structure there still looks polymorphic. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
