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
