> The format of receiverPublicKey / receiverPrivateKey is up to the HPKE library.
This is the part I was surprised to learn, I assumed it had to be a COSE Key. I now understand that HPKE is compatible with multiformats or JWK... or any other key representation. HPKE does not have a preference for key representations at all! However this raises another (probably painfully obvious) result... Just to spell it out... Sender might Seal to a JWK using an HPKE library A. Receiver might Open with a COSE Key using a different HPKE library B. Receiver might Open with a Multformat Key using a different HPKE library C. If this is correct, I am sorry it took so long to understand this. Thanks for your patience. Regards, OS On Wed, Sep 28, 2022 at 3:10 PM Richard Barnes <[email protected]> wrote: > > On Wed, Sep 28, 2022 at 3:56 PM Orie Steele <[email protected]> > wrote: > >> > 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. >> > > Yes, but that public key goes into the HPKE library -- not into the COSE > object. The HPKE API is roughly [1]: > > (enc, ciphertext) = Seal(receiverPublicKey, plaintext) > plaintext = Open(receiverPrivateKey, enc, ciphertext) > > The format of receiverPublicKey / receiverPrivateKey is up to the HPKE > library. What COSE needs to do is convey: > 1. enc > 2. ciphertext > 3. an indication to the receiver as to which private key to use (e.g., > "kid" in JWS/JWE) > > None of those three things is a public key, unless you want to use the > public key as an identifier for the private key. > > --RLB > > [1] https://www.rfc-editor.org/rfc/rfc9180#section-6.1 > > >> >> 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> >> > -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
