Thanks for the detailed comments, Ilari. Let me provide comments below:
-----Original Message----- From: [email protected] <[email protected]> Sent: Monday, January 17, 2022 12:19 PM To: Hannes Tschofenig <[email protected]> Cc: [email protected] Subject: Re: [COSE] draft-ietf-cose-hpke-00 and proposed changes for -01 On Mon, Jan 17, 2022 at 09:36:34AM +0000, Hannes Tschofenig wrote: > > with draft-ietf-cose-hpke-00 I have submitted the draft version that > was subject to the working group call for adoption. John and Goeran > provided feedback already and suggested to re-use the algorithm > registry created by HPKE. > > In https://github.com/cose-wg/HPKE/blob/main/draft-ietf-cose-hpke.txt > the proposed -01 version can be found. > > Please have a look at it and let me know if the proposed changes are > inline with the suggestions. In can make little sense of the way HPKE is used. - Why are the symmetric and asymmetric parts of HPKE split into two different layers? The whole point of HPKE singleshot mode is to combine them. [Hannes] We are adding another layer to allow for additional use cases. The use case is to encrypt a payload once for different recipients. - The layer 1 algorithm is specified as COSE encryption algorithm, but for actually performing the encryption/decryption, one needs HPKE AEAD ID. [Hannes] Layer 2 uses the KEM algorithms from Section 7.1 of the HPKE spec: https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke-12#section-7.1 Layer 1 uses the COSE algorithms instead of the algorithms in Section 7.3 of the HPKE spec https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke-12#section-7.3 * How is the mapping between the two done? * If new AEAD is added to HPKE, does one also have to register COSE algorithm for it? Embedding the registry would mean 5 byte algorithm identifiers, as there is just not enough space with smaller ones (need continuous block of 65534 (sic) algorithm ids). [Hannes] It is possible to re-use the AEAD ID values from the HPKE spec instead of the corresponding COSE algorithms. However, there is not much of variation between the AEAD algorithms in COSE vs. the HPKE spec. - Recipients at layer 1 are specified as one-or-more. AFAICT, more than one recipient here makes absolutely no sense. [Hannes] It makes sense if you consider the use of firmware encryption. There, you want to have one CEK to encrypt the firmware image but multiple recipients. - The algorithm ID at layer 2 needs new registrations to take advantage of new HPKE algorithms. This especially inclures KEMs, which are one of the most important extension points (post-quantum!). [Hannes] By re-using the HPKE registry the idea was to re-use new KEMs as they come along. - Decomposing the keys at layer 2 needs code changes to support new KEMs. Which likely can not be nontrivially decomposed anyway. However, currently HPKE does not have compact NIST curves, which allows space saving via decomposition. Compromise might be to embed the registries (both may be jointly embededed into 5 byte algorithm identifier) and have special values for decomposed stuff (and shorthands for X25519/X448).[1] If both KEM and KDF can be sepcified, the KDFs SHOULD be matched. [Hannes] There is obviously a downside to the re-use of the HPKE registry, as you point out. Splitting the registry into two appears quite complex to me. Adding new KEMs will, of course, require code changes. We should indeed think carefully whether this registry re-use offers enough benefits to do it. - HPKE is different enough that I think both new kty and a new operational mode are justified (I can make very little sense of existing operational modes). [Hannes] We are currently only using the base mode from the HPKE spec and utilize the COSE capabilities for authentication. The kty is used to describe the encapsulated key and there is no difference in the keys. - Doing HPKE with two layers with cose_encrypt, easily extends to doing HPKE in cose_encrypt0: The only difference is directly operating on the plaintext instead operating on the CEK. The limitation is only having one recipient. [Hannes] If the group wants a variant of COSE-HPKE that supports hybrid public key encryption for a single recipient only then I will, of course, do it. However, it is not clear to me whether this few additional bytes justify the extra variant. More variants = more complexity. Ciao Hannes [1] E.g.: - algid=-1 is like algid=0x00010010, but key is compressed like in C509. - algid=-2 is like algid=0x00020011, but key is compressed like in C509. - algid=-3 is like algid=0x00030012, but key is compressed like in C509. - algid=-4 is alias for algid=0x00010020 (X25519 with SHA-256). - algid=-5 is alias for algid=0x00030021 (X448 with SHA-512). -Ilari 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
