Hi Ilari,

So you rely on the assumption that a P-256 curve will also be used with 
HKDF-SHA256?

Regarding the key format I noticed that your P256 key format differs from what 
the group has been using so far.

Here is what you have:

> P256 public key:
>
> {
>         1: 1,                     / kty => OKP /
>         2: h'1F677209D1C5174C',   / Some random kid /
>         -1: -65537,               / crv => -65537 (HPKE P256 with SHA256) /
>         / Raw public key data, 65 bytes /
>         -2: 
> h'040E271193AE34E989C5BDD36A8AF81391B62A2501A49203EA7511B5CC4E44A5753FAB35EA9E5FDEAF037E2B24CB1FF21C4C4AF1ED8AF3A91C4FECF69187DA4369'
> }

Here is what has been used in the group before (for example in key sets):

{
   / kty / 1:2,
   / kid / 2: h'1F677209D1C5174C',
   / crv / -1:3,
   / x / -2:h'0072...85e5c8f42ad',
   / y / -3:h'01dc...fe1ea1d9475',
},

Couldn't we just use one format for expressing the public key?

Ciao
Hannes

-----Original Message-----
From: COSE <[email protected]> On Behalf Of Ilari Liusvaara
Sent: Monday, July 11, 2022 11:20 AM
To: [email protected]
Subject: Re: [COSE] HPKE: Ephemeral public key encoding

On Mon, Jul 11, 2022 at 07:16:26AM +0000, Hannes Tschofenig wrote:
> Hi Ilari,
>
>
>
> You combined the KEM and KDF into one value (such as 
> COSE_CRV_HPKE_P256_SHA256).
>
>
>
> The issue I am raising is that in the example messages (not the
> example keys*) this value is not communicated.

I don't communicate it in message, because there is exactly one value that 
could work: Whatever matches the private key.

And by the time implementation gets to even trying to open the HPKE message, it 
already has to have the private key available.

> While the curve can be inferred from the included public key, the KDF
> is actually not shown in the message structure itself.

My code does not even try to figure this out. It just grabs the information 
from the private key.

And this is not robust: Imagine compact P-256 gets added. It has 32 byte 
uncompressed keys, so it can not be reliably distinguished from x25519, which 
also has 32 byte uncompressed keys.

> Imagine I receive a COSE structure, like the one below -- an example
> COSE-HPKE two-layer structure, how do I find out what KDF to use?

My code picks that too from the private key.

> *: In your examples, what are the public keys representing? Are those
> the long term public keys of the recipients in a kind of key set
> style?

Actually a single long term public key of recipient. The cose key sets are just 
arrays of those.

I just added support for key sets to my implementation (one could specify 
multiple keys for encryption and decryption anyway). My implementation figures 
out private keys to use automatically, albeit it can only attempt one 
decryption of cose_encrypt0. However, that attempt will come after KID 
filtering, so as long as KIDs do not clash, it will work.



-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

Reply via email to