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 >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
