Thanks for this email, responses inline: On Sat, Sep 3, 2022 at 9:43 AM AJITOMI Daisuke <[email protected]> wrote:
> 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... > I agree, this is a major problem.. but it's not limited to COSE, it's also a concern for JOSE... and PGP.... and SSH... It is, in general, a function of the way we define registries for "keys", "algorithms", "signatures" and "encryptions"... Your libraries will almost certainly need to support several RFCs to be useful... and you may be required to publish several new RFCs (and update several IANA registries) to add a new capability to an existing library. There have also been several publications from NIST and others since the JOSE and COSE conventions were established... without getting into the details of them, here are a couple design principles that lead me to support the unfortunate need to make so many registry updates: 1. Keys should be used for one purpose, and under one algorithm. 2. From 1, follows that kty, alg should be set at the time of key generation... not after it, when a key gets used. 3. Explicit over implicit 4. From 3, don't attempt to "infer" `alg`... require it... for example, P-256 can be used for signatures and encryptions, when `alg` and `use` are absent, inference is ambiguous without sufficient context. 5. From 4, If you invent a new alg, you must register it and its association to keys and signatures / encryptions. There are 2 registries that will need to be updated in order for your new "alg" to be understood. - https://www.iana.org/assignments/jose/jose.xhtml - https://www.iana.org/assignments/cose/cose.xhtml I interpret this as an answer to your question... There __is__ a guarantee that `enc` can be mapped to `COSE_Key` in the future, but only for `enc` and `COSE_Key` that have been properly registered, and not before that, can they be safely used with COSE. I'm not really a COSE or HPKE expert so take this as what I would expect to be true based on my experience... and yes, I sympathize with needing to update registries to ensure interoperability. Systems that are more "open world", might have more registries or even an unbounded number of registries... but they all still need to be updated to ensure interoperability. > 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. > https://datatracker.ietf.org/doc/html/rfc9180#section-11.2 https://datatracker.ietf.org/doc/html/rfc9180#section-5.1 However, I am not sure this answers your question... are you expected to see scenarios where there are multiple `kdf_id` here https://datatracker.ietf.org/doc/html/rfc9180#appendix-A.2.3 ? > 3) There is no point in specifying kty (and crv) as required parameters. > It is a waste of bytes. > It's required to represent keys in a standard manner, see my comment above... not disagreeing with your point, but it seems not aligned with the conventions used by the standards... This has been my comment to ilari as well. > 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? > wondering which "original" definition you are thinking of here... - https://datatracker.ietf.org/doc/html/rfc8037#section-2 - https://datatracker.ietf.org/doc/html/rfc7518#section-6.2.1.1 - https://datatracker.ietf.org/doc/html/rfc8152#section-13.2 The last one seems most relevant to your question. > 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. > I'm struggling to visualize how this would actually work based on the text in this email, and your example. As a developer, I'm expecting something like this: standard_ciphertext = encrypt ( standard_msg, standard_public_key, ?alg ) ... where either standard_public_key contains `alg` or it is required as an additional argument if absent... we know it can be absent, due to being optional. standard_msg = decrypt ( standard_ciphertext, standard_private_key ) ... where standard_ciphertext signals `alg` so it does not need to be in `standard_private_key` or passed as an additional argument. Assume I have a key pair in COSE_Key format... How do I use them for your new HPKE cipher suite, with your new `alg` ? Is it possible your simplifications are based on assumptions regarding the crypto system used for the keys? Like "we can guess the `alg` for "y^2 = x^3 + ax + b (mod p)." or similar? I am hearing you say, we don't need a standard way to represent the keys for a new `alg`. Are you hoping to use new "unregistered alg" with existing keys in the future? For example: - ECDSA over secp256k1, alg: ES256K vs - Schnorr over secp256k1: SS256k ... this is not registered, but I've explored it as a concept.... https://identity.foundation/SchnorrSecp256k1Signature2019/ ... Possibly, I am just too naive to HPKE... can you try to explain this again? - 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 > -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
