Hi Hannes and folks > The challenge is that the COSE WG has already defined formats for certain public keys and, at least at the last IETF meeting, was in favor of using those existing key formats.
Thanks for your information, I've watched the recorded IETF114 meeting. Regarding Ilari's proposal, I agreed with his attempt to treat ”enc" (encapsulated sender's public key) as an octet string, but I did not agree with his attempt to force the use of the COSE_Key structure, and I thought the current specification format was relatively better. 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. The fact that the output of KEM is an octet string of the raw key is specified by the HPKE specification so the comments are obvious misunderstandings. Anyway, both Ilari's proposal and the current draft are based on the use of COSE_Key for representing an enc (a sender's public key), which I believe has the following problems: 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. As a library implementer (I'm also a COSE/CWT implementer https://github.com/dajiaji/python-cwt ...), I cannot overlook this... 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.) Please allow me to suggest a solution to the above problems. It is just an idea that is not very refined yet though: 1. Define 'HPKE'(COSE_ALG_HPKE) as a new 'alg' value for a COSE Header Parameter. Unlike the current draft, AEAD information is not included in the alg value. 2. Introduce a new 'HPKE sender information' structure including enc as a parameter of 'HPKE' alg, instead of using the COSE_Key structured ’ephemeral key'. The structure also includes the HPKE cipher suite information(at least KDF ID and AEAD ID are required) negotiated with the recipient. An example is as follows: ``` 96( [ / algorithm id TBD1 for COSE_ALG_HPKE / << {1: TBD1} >>, { / HPKE sender information structure / -4 (TBD2): << { / KEM identifier, 2bytes (optional because (the recipient's)kid can be mapped to a KEM id.) / -1: 0x0010, / HPKE symmetric cipher suite (KDF id + AEAD id), 4bytes (required) / 1: 0x00010001, / HPKE encapsulated key (required) / 2: h'xxxxxxxxxxxxxxxxxxxxxxxxxxx', } >>, / the recipient's public key identifier (required) / 4: 'kid-2' }, / encrypted plaintext / h'4123E7C3CD992723F0FA1CD3A903A58842B1161E02D8E7FD842C4DA3B984B9CF' ] ) ``` I think the problems with the current draft listed above have been resolved in my proposal: - Once the new COSE parameters above are defined, even if HPKE cipher suites are added, there is no need to register new alg/crv values to IANA registry, no need to specify how to convert to COSE_Key, and no need to change the existing library implementations. - KDF information is also included. - The information is reduced to the minimum necessary. - No misuse of existing parameters that deviates from their original meaning. - There is no need to implement unnecessary parameter validation in conjunction with the adoption of COSE_Key. Could you please consider my proposal? Regards, Daisuke 2022年9月2日(金) 1:25 Hannes Tschofenig <[email protected]>: > Hi Ajitomi, > > > > The challenge is that the COSE WG has already defined formats for certain > public keys and, at least at the last IETF meeting, was in favor of using > those existing key formats. > > > > Having multiple ways to encode the same information is not great. > > > > Ciao > > Hannes > > > > *From:* COSE <[email protected]> *On Behalf Of * AJITOMI Daisuke > *Sent:* Thursday, September 1, 2022 4:01 PM > *To:* Ilari Liusvaara <[email protected]> > *Cc:* [email protected] > *Subject:* Re: [COSE] Next steps with COSE-HPKE .... was RE: HPKE: > Ephemeral public key encoding > > > > Hi Hannes and Ilari > > As an implementor of HPKE library (https://github.com/dajiaji/hpke-js), > let me offer my opinion. > > I strongly agree with Ilari's opinion. > > I don't know what kind of discussions were held in IETF114, HPKE spec > (RFC9180) defines that a sender's ephemeral key (enc : encapsulated key) > output by KEM is an octet string. > I see no point in converting to the existing public key structure (JWK for > COSE), which would rather lead to more complex specifications and > implementations, and cause security issues. > > Of course, existing key structures could be used to represent the > recipient's public key. > > However, the sender's ephemeral key depends on the recipient's public key > information, and there is no need to specify the many parameters such as > kty, crv, alg, etc. which is already determined by the recipient's public > key. > > In my opinion, the required attributes for the sender's ephemeral key > related information are as follows: > - kid: bstr. the recipient's public key identifier. > - ek (or enc?): bstr. the sender's ephemeral public key. > > - kdf: int(2-byte). optional. the KDF identifier selected by the sender if > the recipient's public key supports more than one KDF algorithm. > - aead: int(2-byte). optional. the AEAD identifier selected by the sender > if the recipient's public key supports more than one AEAD algorithm. kdf > and aead might be able to be combined into one parameter. > > - ver: int (2-byte). optional?. the version of the HPKE application. An > HPKE application will probably specify how to use INFO and AAD. It is > necessary to define a version of the specification which could be updated. > > Finally, I think we can learn a lot from other standards that use HPKE: > ECH, ODoH, and OHTTP quite naturally use "enc" as it is, as an octet string. > > Regards, > Ajitomi, Daisuke > > 2022年8月30日(火) 23:11 Ilari Liusvaara <[email protected]>: > > On Mon, Aug 29, 2022 at 11:47:27AM +0000, Hannes Tschofenig wrote: > > Hi Ilari > > > > The participants of the IETF#114 meeting expressed an opinion about > > the approach of how to encode the public key in a COSE message, namely > > to re-use the structures already defined. Those map nicely to what is > > being defined for HPKE in terms of algorithms as well. > > Well, turns out x25519 and x448 do not quite map nicely to present > structures: The encapsulated key is octet string, but putting it to eph > requires some extra junk. At best this wastes space. At worst it causes > security issues. > > Assuming redefining eph to allow bstr is not acceptable (compare > allowing kid to be int), solving this would require a new header that > can take bstr and cose_key. E.g., "ek" (encapsulated key). Which would > also be used by native KEM modes. > > Such header would be useful for backport to JOSE, since there > presumably will not be JOSE-HPKE, so PQC requires native KEM modes > for JOSE. > > > For long-term keys, one could specify that HPKE keys MUST be OKP unless > specified otherwise. This would allow reusing existing x25519 and x448 > key structures without causing a long-term mess. > > > > For PQC algorithms the work on these encodings is still ongoing and I > > am sure they will be re-usable as well. > > Well, judging from what I have seen about PQC (signature) work on > COSE/JOSE, I do not think the codepoints will be reusable. > > And then there might be some non-PQC additions, like compact NIST > curves. Those things would obsolete the current NIST curves in > COSE-HPKE. There are no encodings to reuse for these. > > > > In terms of implementation effort, the biggest work is on implementing > > the PQC algorithm and the integration of it into HPKE not in the > > integration with COSE (where we are talking about a few lines of code > > only anyway). > > That is true only if the algorithm is not special in any way. > > If there is anything special in the way the algorithm is mapped to > COSE, the complexity leaps up greatly: Specification is entiere > document instead registry entry. And implementation will be way more > than a few lines (one line in my test implementation). E.g., in > hundreds of lines range with NIST curves. > > > > -Ilari > > _______________________________________________ > 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
