> My point is that you as a COSE implementer should not have to know the answers to any of these questions.
I appreciate this, a lot... but I need to understand how HPKE works to decide if I want to implement support for it. As an implementer, I don't start with an "opaque byte string" from my HPKE library... I start with a public key in a standard format, such as JWK or COSE Key. I might even start with a public key in a compressed format represented using multicodec: https://github.com/multiformats/multicodec/pull/190 I keep assuming that I would need to transform that key into a format for HPKE to work... Maybe this is my invalid assumption. Maybe I am hearing you say that it's legal to use multicodec with HPKE? ... If so, that's pretty cool. My use case is that I already have a published P-256 Public Key in a standard format (JWK, COSE Key, Multibase)... I'm looking at https://www.rfc-editor.org/rfc/rfc9180.html#name-dhkemp-256-hkdf-sha256-hkdf 04a92719c6195d5085104f469a8b9814d5838ff72b60501e2c4466e5e67b325ac98536d7b61a1af4b78e5b7f951c0900be863c403ce65c9bfcb9382657222d18c4 I am guessing, based on my experience <https://en.bitcoin.it/wiki/Elliptic_Curve_Digital_Signature_Algorithm>, ^ this is an openssl generated P-256 Public Key in expanded format 0x 04 is the prefix... 0x a92719c6195d5085104f469a8b9814d5838ff72b60501e2c4466e5e67b325ac9 is X 0x 8536d7b61a1af4b78e5b7f951c0900be863c403ce65c9bfcb9382657222d18c4 is Y. Is it legal for me to substitute a multiformat opaque byte string for this value? zDnaebdi2s6nqzYbZUU9LXu52iHUpffkq9oXcefRXF5BuVto2 (P-256 Public Key in compressed format, encoded in base58btc). I assume that if the processor on the other side knows how to translate... The answer is yes. Sorry if this is obvious to the other folks on the list at this point. Regards, OS On Wed, Sep 28, 2022 at 1:31 PM Richard Barnes <[email protected]> wrote: > > > On Wed, Sep 28, 2022 at 2:28 PM Orie Steele <[email protected]> > wrote: > >> Thank you for your reply and links. >> >> > It is **coincidentally** a serialized public key with DHKEM. >> >> How do I produce a "serialized public key" as an "opaque byte string" >> given a public key in JWK / COSE_Key format, say for example I already have >> a P-256 Public Key....? >> >> In the case of P-256 for example, does HPKE assume a compressed or not >> compressed public key for the "opaque byte string". >> > > My point is that you as a COSE implementer should not have to know the > answers to any of these questions. When you send, you should take the > opaque byte string that your HPKE library produces and put it in a slot in > the COSE object. When you receive, you should grab an opaque bytestring > from a slot in the COSE object and put it in the "enc" input to your HPKE > library. If you're doing anything more than that, you're doing unnecessary > work and inviting bugs. > > --RLB > > > >> >> Thanks in advance, >> >> Regards, >> >> OS >> >> On Wed, Sep 28, 2022 at 12:59 PM Richard Barnes <[email protected]> wrote: >> >>> Hi all, >>> >>> It was brought to my attention that this working group is considering >>> representing the "enc" output of HPKE as a COSE_Key as opposed to an opaque >>> byte string [1]. >>> >>> This is a category error and a bad idea. HPKE defines the encapsulated >>> key to be a byte string. It is **coincidentally** a serialized public key >>> with DHKEM. All the HPKE libraries I could find correctly produce an >>> opaque byte string for the "enc" output: >>> >>> Reference implementation: >>> https://github.com/cisco/go-hpke/blob/master/hpke.go#L382 >>> Chrome/BoringSSL: >>> https://boringssl.googlesource.com/boringssl/+/refs/heads/master/include/openssl/hpke.h#213 >>> Firefox/NSS: >>> https://searchfox.org/mozilla-central/source/security/nss/lib/pk11wrap/pk11hpke.c#41 >>> Webex/MLSpp: >>> https://github.com/cisco/mlspp/blob/main/lib/hpke/include/hpke/hpke.h#L198 >>> >>> Representing the "enc" output as anything other than opaque bytes is a >>> mistake. It would require the COSE implementation to parse the "enc" >>> output, causing a bunch of unnecessary work and inviting error. (If you >>> want to represent it as opaque bytes plus some metadata, sure. But But >>> don't parse it.) >>> >>> I'm not sure which of the chairs' options that maps to, but both the >>> COSE_Key and Ilari's OKP proposal look incorrect to me, because they both >>> imply that the value is a key. I think Daisuke Ajitomi's proposal is >>> closer to correct. In any case, I hope this helps clear things up. >>> >>> --Richard >>> >>> [1] >>> https://mailarchive.ietf.org/arch/msg/cose/qzYaUCkogRSt53A3oCaTe-IwQDI/ >>> _______________________________________________ >>> COSE mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/cose >>> >> >> >> -- >> *ORIE STEELE* >> Chief Technical Officer >> www.transmute.industries >> >> <https://www.transmute.industries> >> > -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
