Hi Hannes Thanks for the response.
your design goal is to avoid changes to your COSE code when adding new HPKE > algorithms. Not only code but also the COSE-HPKE specification in itself but yes. It is one of my design goals. 1) There is no guarantee that enc can be mapped to COSE_Key in the future, > so if a new HPKE cipher suite is specified, it cannot be used on COSE > immediately. Whenever a new cipher suite is added to HPKE, it is necessary > to develop a mapping specification for COSE_Key (including alg/crv value > registration to IANA) and implement an additional enc->COSE_Key conversion > process in existing many COSE libraries. 2) When a recipient offers > multiple candidates for the HPKE cipher suite, a sender needs to tell the > recipient what the sender has chosen, and while AEAD and KEM are fine, > there seems to be a lack of a way to tell the recipient about KDF in the > current draft. > 3) There is no point in specifying kty (and crv) as required parameters. > It is a waste of bytes. > 4) crv is used to put in KEM algorithm information, but this is not in > line with the original definition of crv. Isn't this an abuse of crv? > 5) This spec needs to clearly define how COSE_Key parameters are to be > handled, and implementations need to support this. (For example, what to > put in key_ops, and whether to allow "deriveKey" and/or "deriveBits"? etc.) I have previously listed five problems above, each of which corresponds to my design goals as follows. I think not only 1) but also 2) and 3) are important. 1) The addition of a new HPKE algorithm does not cause any changes to the specifications and existing implementations on the COSE side. 2) HPKE cipher suites can be negotiated dynamically and flexibly between a recipient and a sender. 3) The information sent from a sender to a recipient is necessary and sufficient. 4) No abuse of existing specification definitions. 5) Easy implementation (compact specification). The drawback is the definition of a 'HPKE sender information' structure, > which carries all the information HPKE exposes. I don't think it is a drawback, but if defining a new structure is a drawback in itself, so be it. I believe that it is essential for the sender to have a way to inform the selected KDF and AEAD to the receiver in HPKE. This is related to the design goal 2) above. My main interest is to reach a decision as soon as possible so that we can > make progress with the spec. I will ask the chairs to run a consensus call > on the design goal. Okay. Sorry for bothering you with my proposal. Regards, Daisuke 2022年9月16日(金) 0:01 Hannes Tschofenig <[email protected]>: > Hi Daisuke > > > > your design goal is to avoid changes to your COSE code when adding new > HPKE algorithms. The drawback is the definition of a 'HPKE sender > information' structure, which carries all the information HPKE exposes. > > > > I understand that design goal. > > > > It is up to the group to decide whether they share this goal. > > > > My main interest is to reach a decision as soon as possible so that we can > make progress with the spec. I will ask the chairs to run a consensus call > on the design goal. > > > > Ciao > > Hannes > > > > *From:* AJITOMI Daisuke <[email protected]> > *Sent:* Saturday, September 3, 2022 7:11 PM > *To:* Hannes Tschofenig <[email protected]> > *Cc:* Ilari Liusvaara <[email protected]>; [email protected] > *Subject:* Re: [COSE] Wire-format ... was RE: Next steps with COSE-HPKE > .... was RE: HPKE: Ephemeral public key encoding > > > > 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 > > 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
