+1 Hannes Mike Prorock mesur.io
On Thu, Sep 1, 2022, 12:25 Hannes Tschofenig <[email protected]> wrote: > 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 >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
