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
