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> >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
