On Jul 14, 2023, at 1:14 PM, Orie Steele <[email protected]<mailto:[email protected]>> wrote:
You are correct: On Fri, Jul 14, 2023 at 2:48 PM lgl island-resort.com<http://island-resort.com/> <[email protected]<mailto:[email protected]>> wrote: On Jul 14, 2023, at 12:12 PM, Orie Steele <[email protected]<mailto:[email protected]>> wrote: Inline: On Fri, Jul 14, 2023 at 1:09 PM lgl island-resort.com<http://island-resort.com/> <[email protected]<mailto:[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? HPKE libraries will know because the HPKE spec for the new KEM will say. COSE libraries don’t need to know. 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? While pKR (and sKR) are in/out args for Seal() and Open() they are not transmitted in a COSE_Encrypt. So it doesn’t matter for COSE-HPKE what they are. I suppose this is a down side of specifying a protocol with an API. API arguments that are transmitted protocol messages sit right next to arguments that are not with no distinction in the specification. Note that pKR in 9180 is passed completely through and down into DH(). So the format of pKR passed into Seal() only has to be the same as the format consumed by DH(). DH() is just whatever DH API you have. These are all APIs here, not transmitted messages, so pKR could be a key handle or a pointer. LL
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
