Hi Ilari, I have been thinking about this a bit more and the disconnect between your approach and mine is that you assume HPKE defines a wire format for the ephemeral public key. I think it does not, as I mentioned in an earlier email (see https://mailarchive.ietf.org/arch/msg/cose/HL5jG5s2e5c49y3d4w6y_3BDRrA/).
Could this be the case? Ciao Hannes -----Original Message----- From: COSE <[email protected]> On Behalf Of Hannes Tschofenig Sent: Friday, July 8, 2022 11:12 AM To: Ilari Liusvaara <[email protected]>; [email protected] Subject: Re: [COSE] HPKE: Ephemeral public key encoding Hi Ilari, You are proposing this structure(*): -1: { /* kty => Symmetric */ 1:4, /* The raw encapsulated ciphertext. */ -1:h'04ca591f4b1139c1c325be3265a6ce4dcc79a5895e9ef12a0726406bc72282697c8d12f18230208ebaa769f903917d59284526fd65a27ab5898913af10ed334398' } If I look at your email about the algorithm identifiers and copy it into a COSE_Encrypt0 structure then I get this: 96( [ / algorithm id -100 (temp) for COSE_ALG_HPKE_AES_128_GCM / << {1: -100} >>, { / ephemeral public key structure / -1: << { 1: 4, /* symmetric key */ /* The raw encapsulated ciphertext. */ -1:h'04ca591f4b1139c1c325be3265a6ce4dcc79a5895e9ef12a0726406bc72282697c8d12f18230208ebaa769f903917d59284526fd65a27ab5898913af10ed334398' } >>, 4: 'kid-2' }, / encrypted plaintext / h'4123E7C3CD992723F0FA1CD3A903A588 42B1161E02D8E7FD842C4DA3B984B9CF' ] ) Where in this structure is information about the type of key that is being carried here? Where would the curve identifier go in your examples (since it is not included in your snippet)? How do you distinguish between compressed and uncompressed point representations? Ciao Hannes PS: I wonder whether the encoding of an ephemeral public key as a symmetric key will cause confusion among developers and readers. I am tempted to just define a new COSE Key Type instead. -----Original Message----- From: COSE <[email protected]> On Behalf Of Ilari Liusvaara Sent: Friday, June 24, 2022 3:29 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 wrote a test implementation of embedding HPKE in COSE (passes some smoke tests, like encrypting and decrypting some messages, at this point). The main way it encodes HPKE encapsulated keys is in eph (-1) field in unprotected header bucket. The kty is set to symmetric (4) and the k (-1) field contains the raw encapsulated key. Alternatively, if using NIST curves, the encapsulated keys may be compressed. In this case, kty is set to ec2 (2), crv is set to the curve used, and x and y fields encode the curve point. For X25519 and X448, no compression is possible, and the symmetric encoding must be used. Alternatives considered include: 1) Encode the raw encapsulated key into byte string in eph field in unprotected header bucket. This violates RFC 8152, since eph is specified to be cose_key. 2) Encode the raw encapsulated key into byte string in new header field in unprotected header bucket. This would require a new codepoint. 3) Prepend the raw encapsulated key into the ciphertext. It is even fixed-length once kem is known, so it does not need a length field. This presents complications if one wants to compress keys. -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 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
