Hi Ilari, Thanks again for your input. A few responses below:
-----Original Message----- From: [email protected] <[email protected]> Sent: Friday, January 21, 2022 3:18 PM To: Hannes Tschofenig <[email protected]> Cc: [email protected] Subject: Re: [COSE] draft-ietf-cose-hpke-00 and proposed changes for -01 On Fri, Jan 21, 2022 at 01:15:50PM +0000, Hannes Tschofenig wrote: > Hi Ilari, > > You are again raising good points, namely > > 1) Should we convey the KEM ID, and KDF ID explicitly? I think so. Well, I think that all HPKE algorithms should be supported in generic way, so that COSE does not have to deal with registering HPKE algorithms the second time. [Hannes] I checked the TLS ESNI spec and there, if I understand correctly, the KEM ID is not explicitly communicated. The KDF ID is. > 2) If we do, where should this information go? You suggest to put them > into the COSE key (ephemeral key) structure. I would have thought that > the unprotected header would be more appropriate but I do not really > have a strong preference. Well, for KDF id, one could stick it either inside ephemeral key structure, or the main headers. [Hannes] What would be your preference? However, I think that one will run into cases where: - KDF is implicit from KEM. E.g. KEM 17 is probably combined with KDF 2. - KDF is not implicit from KEM. E.g. KEM 48 goes with KDF ???. [Hannes] In the ESNI spec, the KDF is explicitly communicated in the HpkeSymmetricCipherSuite structure. Regardless of whether some parameters can be communicated implicitly or explicitly, there is still the question about where the information has to go. (What is KEM 48?) > 3) Should we define a new kty id? If we place the KEM ID and the KDF > ID into the COSE key structure then I think it would be a good idea to > define a new kty id. Well, there are not just HPKE encapsulated keys, HPKE also has public and private keys. While reusing OKP for generic case would be possible (at cost of a few bytes, since crv will be pushed to 5 byte territory), I think new kty would be cleaner. [Hannes] Having a new kty id parameter is OK for me. I am not sure what you mean by "HPKE also has public and private keys". The newly defined structure is supposed to communicate only the ephemeral public key > I am curious what others in the group think about this idea. > > I lost you when you are were talking about the "size issues" and tried > to solve the issues. Maybe you could elaborate a bit what problem you > see. The size issue is that HPKE currently uses uncompressed P-256/P-384/ P-521. This makes public keys and ephemeral keys a few dozen bytes larger than they should be if one uses NIST curves. And I came up with two ways of representing compressed ephemeral key (and public key). [Hannes] Thanks for the clarification. > IMHO we cannot use COSE_Encrypt0 because we need the recipient > structure, which is not present with the COSE_Encrypt0. HPKE itself does not seem to need the recipient. [Hannes] Here is how I understand COSE: " COSE_Encrypt0 is used when a recipient structure is not needed because the key to be used is known implicitly." So, the "recipient" structure is really only the name of the place where certain information is supposed to go. In my understanding we have to put the HPKE related info into the recipient structure. > You also seem to define new key formats. What prevents us from > re-using the existing COSE key formats? Section 13 of RFC 8152 defines > various ECC key formats and those could be re-used. > Since there is no compressed point format, we could add it. One of the ideas I had for key compression was reusing the existing formats. And these are the cases where there is an obvious KDF to use. Then there is question how generic HPKE keys should be presented. [Hannes] If you also want to introduce support for compressed ECC keys then it makes sense to introduce a new kty id. > I am also not sure why you talk about PQC algorithms. Neither COSE nor > HPKE define PQC algorithms. Do you think we should define them in this > document? I am expecting that once NIST comes with PQC algorithm recommendations, those will be added to HPKE. And with generic HPKE algorithm support, those would be immediately usable in COSE. [Hannes] To have them immediately usable the COSE fields have to exist where they should be placed. Why is the immediate usage so important? Most likely specification work will be needed by the HPKE authors as well since it is not just about adding an entry to the IANA registry. Ciao Hannes -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
