Hi Hannes, > First, the HPKE RFC says that it does not specify a wire-format. In fact, Section 10 of RFC 9180 is very explicit about this fact by saying “This document does not specify a wire format encoding for HPKE messages.”
Yes, you are correct. There is not any wire format definition in the HPKE spec. The wire format should be defined by a higher-level protocol, and indeed I know ECH, ODoH, and OHTTP define it. However, the encapsulated key (sender's ephemeral public key) output by KEM is a byte string and it is evident in the definition of Nenc in the HPKE RFC as follows. > Nenc: The length in bytes of an encoded encapsulated key produced by the algorithm All HPKE implementations output enc as a sequence of bytes. How this is transmitted is left to the higher-level protocol, but it would normally be put directly into the wire format. Indeed, ECH, ODoH and OHTTP do just that. I think the problem is that there is little necessity to convert enc as a byte string to COSE_Key structure. There are many disadvantages as I mentioned, but the reason to convert is just because there is already a field (ephemeral key) defined, right? In my opinion, the ephemeral key (COSE_Key) is inadequate to represent HPKE sender information including enc, and in addition, there is no assurance that it can be converted to COSE_Key in the future. I believe it is very important that when new HPKE cipher suites are defined in the future, this specification and existing COSE library implementations need not be changed. This is easily achievable as described in my proposal. > I will read through your proposal. Thanks for taking your time. Regards, Daisuke 2022年9月4日(日) 0:47 Hannes Tschofenig <[email protected]>: > Hi Daisuke, > > Let me give you a very quick response on one item. I will read through > your proposal. > > ➢ One point of concern during the IETF 114 meeting was there were several > erroneous comments that the fact that enc is an octet string is > implementation-dependent. > > We had discussed this earlier on the list and there are two data points: > > First, the HPKE RFC says that it does not specify a wire-format. In fact, > Section 10 of RFC 9180 is very explicit about this fact by saying “This > document does not specify a wire format encoding for HPKE messages.” > > Second, since Ilari did not believe me I reached out to Chris Wood, one of > the authors, and ask him personally. He confirmed my observation. > > The pseudo-programming language API defined in the HPKE RFC is not > mandatory to implement by an HPKE library. In fact, there are > implementations that do not implement that API and they are still compliant > to the HPKE RFC. An example is the HappyKey implementation by Stephen > Farrell. I used his implementation and used the PSA Crypto API rather than > OpenSSL. > > Ciao > Hannes > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose the > contents to any other person, use it for any purpose, or store or copy the > information in any medium. Thank you. > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
