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
