Hi Ilari, Hi all, There seems to be some confusion about whether HPKE defines a wire format for keys.
Here is what the RFC says: " 10. Message Encoding This document does not specify a wire format encoding for HPKE messages. Applications that adopt HPKE must therefore specify an unambiguous encoding mechanism that includes, minimally: the encapsulated value enc, ciphertext value(s) (and order if there are multiple), and any info values that are not implicit. One example of a non-implicit value is the recipient public key used for encapsulation, which may be needed if a recipient has more than one public key. " I think this is pretty clear. On top of this I have asked Chris Wood (co-author of the HPKE RFC) and Stephen Farrell (author of an HPKE library for OpenSSL) to confirm that HPKE does not specify a wire format for keys. They agreed. As the RFC indicates we have to provide a way to encode - the encapsulated value enc, - ciphertext value(s) (and order if there are multiple), and - any info values that are not implicit Having said that COSE allows two ways to encode keys of type "EC2", as you also mention in your email below and as I just posted to the list as well, and they work for NIST curves (P-256r1, P-384r1, P-521r1). You bring up X25519 and X448 KEMs, which use the key type "OKP" (Octet Key Pair). Using OKP requires the crv parameter since somewhere you have to indicate what type of key it is. Regarding future KEMs: draft-harkins-cfrg-dnhpke-01 is still an individual draft and it remains to be seen whether it will get standardized. It makes me wonder whether it is unavoidable to have new KEMs to go through some standardization also in the COSE WG to decide how they are best encoded (if they do not fit into an existing pattern). We can hardly anticipate every new HPKE KEM people will propose. I prefer to standardize those HPKE KEMs first where we know how they look like and where they will be implemented. If Dan cares about the COSE usage, he may register his new KEMs for COSE HPKE usage as well. If you think we should create a new key type then we should take a look at it. We will have to encode the same information in this new structure and you seem to have an idea how you would want this new key structure to look like. Ciao Hannes PS: From your response below I can see that we have an agreement that the protected header is not the right place to place the key. -----Original Message----- From: COSE <[email protected]> On Behalf Of Ilari Liusvaara Sent: Monday, April 25, 2022 7:39 PM To: [email protected] Subject: Re: [COSE] HPKE: Ephemeral public key encoding On Mon, Apr 25, 2022 at 03:56:24PM +0000, Hannes Tschofenig wrote: > Hi Ilari, > > > 6) The encoding of the encapsulated key produced by HPKE seems to be > > under-specified. > > > > HPKE gives octet string as encapsulted key. This apparently is > > placed into the ephremeral public key field in unprotected header. > > However, > > RFC8152 specifies this field to be cose_key, and it is not at all > > clear how to encode the octet string as cose_key. Especially what to > > fill as the kty field, which is mandatory in cose_key. > > > > Searching for existing RFC8152 construct to abuse, there is the > > "Symmetric" kty. Then the encapsulated key would look like: > > > > -1: { > > /* kty => Symmetric */ > > 1:4, > > /* The raw encapsulated ciphertext. */ > > > > -1:h'04ca591f4b1139c1c325be3265a6ce4dcc79a5895e9ef12a0726406bc72282697c8d12f18230208ebaa769f903917d59284526fd65a27ab5898913af10ed334398' > > } > > You raise a couple of good questions in your remark: > > > 1. Is the unprotected header the right place to put the ephemeral > public key? > 2. What kty field should be used in the ephemeral public key > structure? > 3. What is the encoding of the public key exported by HPKE? > > Add 1) We used the unprotected header because this is also currently > done for similar uses in the COSE RFC. See, for example, Appendix > C.3.1. > > Add 2) Regarding the kty field the IANA registry contains a number of > "COSE Key Types" in https://www.iana.org/assignments/cose/cose.xhtml. > For use with elliptic curve keys EC2 (2) appears appropriate. > > Add 3) HPKE does not define a wire format. The COSE-HPKE draft defines > a wire format. Hence, there is no conflict in terms of encoding. > It appears to make sense to re-use the already existing encoding > provided in the COSE spec. I do not think that is correct. HPKE effectively does define a wire format. It is byte string, that is constant-length (w.r.t. KEM used). There are essentially three choices about where to stick that (can not use protected headers, because hard cyclic dependency with single-shot HPKE API): A) Into unprotected ephremeral key header. B) Into unprotected new KEM ciphertext header. C) Prepend to ciphertext (no length field needed). Then HPKE itself can not deal with EC2 keys. However, an application could transform EC2 keys into correct format for HPKE. With such transform, the above example key would be encoded as: -1: { /* kty => EC2 */ 1:2, /* Uncompress as P-256 point. */ -1:1 /* The x-coordinate. */ -2:h'ca591f4b1139c1c325be3265a6ce4dcc79a5895e9ef12a0726406bc72282697c' /* Sign bit for y-coordinate. */ -3:false } However, this is _not_ the encapsulated key, it is _compression_ of the encapsulated key (encoding 65 bytes using 40 bytes). If one uncompresses the above, one obtains the following actual encapsulated key (as in the above example key): 04ca591f4b1139c1c325be3265a6ce4dcc79a5895e9ef12a0726406bc72282697c8d12f18230208ebaa769f903917d59284526fd65a27ab5898913af10ed334398 Which can then be used with HPKE. However, things get harder with HPKE using the X25519 and X448 KEMs. There is no useful compressed form: There are too many main subgroup elements to shave even one byte via any means. What should be kty be here? - Omitting kty entierely violates RFC8152. - Using OKP requires crv, which is pure overhead for no useful purpose. - 'Symmetric' is ugly, but gives least overhead possible. - There might not be a new kty, because public/private key shape of HPKE with fixed KEM and KDF is OKP. - No other kty seems to work at all. And for even harder cases, consider some future KEM that does not correspond to any known kty in COSE. What the kty should be here? - Omitting kty entierely violates RFC8152. - Using OKP needs new crv, which is too heavy operation for the WG. - 'Symmetric' is ugly, but gives least overhead possible. - Dedicated HPKE kty would have similar issues as with x25519/x448. Dedicated kty for KEM would be too heavy operation for the WG. - And again, no other kty seems to work at all. And there is already a draft that proposes a new KEM corresponding something not in COSE: draft-harkins-cfrg-dnhpke-01 proposes three new KEMs with compact NIST curves, which are something COSE does not have. And there is a more subtle issue with this for COSE-HPKE: It would make the above EC2 trick useless (as just using compact curves is superrior in every way). In case HPKE gets compact NIST curves, there is no reason to ever treat the encapsulated key as anything else than byte string with no substructure (SIKE is much too heavy for anything where the size savings would matter). -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
