You are correct: On Fri, Jul 14, 2023 at 2:48 PM lgl island-resort.com <[email protected]> wrote:
> > On Jul 14, 2023, at 12:12 PM, Orie Steele <[email protected]> > wrote: > > Inline: > > On Fri, Jul 14, 2023 at 1:09 PM lgl island-resort.com < > [email protected]> wrote: > >> Looks to me that HPKE internally defines what “enc” should be. The >> formatting of “enc” is an internal HPKE issue. It happens to be a >> serialized public key produced by the HPKE SerializePublicKey() function, >> but no one but the HPKE libraries need to know that. >> >> Why would any thing other than an HPKE library ever look inside “enc”? >> > > Exactly, and since it's "opaque"... such a library can output whatever it > likes... possibly randomly alternating between valid opaque > representations.... > > > No, it absolutely can not output whatever it likes. It can only output > what RFC 9180 says and I don’t see any ambiguity in 9180 on what these > bytes are. > > Maybe the confusion is because RFC 9180 is written in the form of a Python > API? It is unconventional, but I don’t see any problems with it being > ambiguous or non-interoperable so far. > https://datatracker.ietf.org/doc/html/rfc9180#name-dh-based-kem-dhkem In the case of DH Kem, HPKE defined a new way to serialize a public key... which can be translated or not... depending on downstream implementer preference.... It also defined only DH Kems... https://datatracker.ietf.org/doc/html/rfc9180#kem-ids So how do we know what a non dh kem will output? How do we know Kyber1024+Secp256k1 does not output a COSE KEY? I read https://datatracker.ietf.org/doc/html/draft-westerbaan-cfrg-hpke-xyber768d00-02#section-3.4 To learn that `enc` will be the concat of a DHKem and Kyber.... (and maybe this changes). I could write a draft that says "Kyber1024+Secp256k1" is like that but outputs a COSE Key instead... All I need to do is define the KEM functions... as functions of a known key serialization... What exactly is pkR? Can pkR be a JWK or a COSE Key? As you said, it would be a layer violation ( I agree with this statement ), and probably the HPKE registry would reject the attempt to register a Kem that takes a dependency on a foreign key representation ( like JWK or COSE ).... Should the experts for COSE do the same for HPKE?... Maybe... When you use JOSE or COSE, you expect certain conventions. We don't need to copy paste HPKE and call CBOR encode... but... If the working group believes that is the correct way to represent HPKE in COSE... that is what we will do. I don't think that's a good design, but I don't dispute that it will work. > LL > > > > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
