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/9914fa6f84b28046ee29762551798760dbaa3b7f/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
