Re: [COSE] draft-ietf-cose-hpke-00 and proposed changes for -01

[Ilari Liusvaara <[e-mail]>]

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.

> 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. 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 ???.

> 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.

> 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).

> 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.

> 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.

> 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.


-Ilari