Hi Daisuke, I have been working on code that is meant to be used on IoT devices. So, my focus is on reducing the overall code size on the device.
Imagine there is a library implementing the COSE specification (or most of it). The COSE spec already defines various public key formats. Now, you are implementing COSE-HPKE and HPKE for this library. With the proposed encodings you are adding new encodings for how to carry the payloads in COSE. That’s what I mean by adding complexity. Just because something is processed in HPKE does not mean that the other code for the key representations in a COSE library suddenly vanishes. How long will it take for someone to come along and to propose various PQC public key encodings in COSE and then again in HPKE? Then, we have even more encodings of the same information. I think I have shared my view on this subject and let other people speak up because so far we have heard mostly from you, me, and Ilari. Ciao Hannes From: COSE <[email protected]> On Behalf Of AJITOMI Daisuke Sent: Monday, September 26, 2022 1:57 PM To: Hannes Tschofenig <[email protected]>; [email protected] Subject: Re: [COSE] COSE HPKE Public Key Format Consensus Call Hi Hannes, > Here is my question to you: How do you deal with this added complexity? As I and Ilari mentioned before, the static recipient's public key and the encapsulated key (sender's ephemeral public key) are different things and the encoding format of them should also be considered separately. Having two encoding schemes is natural, and there is no complexity. From my point of view, the COSE-HPKE specification should only cover the latter encapsulated key format, so I will limit my discussion to the latter. In my proposal, an encapsulated key is a byte string output by the HPKE module as it is, and is put into the COSE message without any unnecessary conversion process. Thus, the implementation is very simple. In addition, there is no need to update the implementation when new HPKE algorithms are added. On the other hand, in the current draft, each time a new HPKE algorithm is added, an additional conversion process must be implemented to convert the encapsulated key to COSE_Key format. Indeed, as you point out, my proposal has 1 (COSE_Key structure for the recipient's public key[1]) + 1 (octet string for the encapsulated key) = 2 ways for key encoding, but the current draft has n + n = 2n (if there are n HPKE algorithms) ways. I think it is clear which is more complicated. In addition, to reiterate what I mentioned in my previous post[2], the encapsulated key is generated and consumed internally (in the COSE-HPKE process).It does not emerge on the COSE interface. While the recipient's public key and private keys need to be expressed with COSE_Key, there is no need to express the encapsulated key with COSE_Key. I believe that the dedicated data structure for HPKE sender information(consists of the encapsulated key and a selected HPKE cipher suite) should be introduced so that the COSE-HPKE process can be implemented as simply, effectively and securely as possible. Best regards, Daisuke [1] https://mailarchive.ietf.org/arch/msg/cose/Rg_AAtgOL4p9SdlXHyL8-0HSrI8/ (I suggested a JWK format for the recipient's public key here) [2] https://mailarchive.ietf.org/arch/msg/cose/IgS66HB4xTySUDb45vQlkJe_etQ/ 2022年9月26日(月) 16:34 Hannes Tschofenig <[email protected]<mailto:[email protected]>>: Hi Daisuke, With your proposal and Ilari’s proposal there are two ways to encode public keys in COSE libraries. This adds complexity. Complexity leads to security problems. Here is my question to you: How do you deal with this added complexity? (FWIW this is not something you mention in your comparison table.) Ciao Hannes From: COSE <[email protected]<mailto:[email protected]>> On Behalf Of AJITOMI Daisuke Sent: Friday, September 23, 2022 12:00 AM To: Mike Jones <[email protected]<mailto:[email protected]>> Cc: [email protected]<mailto:[email protected]> Subject: Re: [COSE] COSE HPKE Public Key Format Consensus Call Thanks for initiating the consensus call. > 3. Other (please describe in sufficient detail to enable its specification) +1 to my proposal described in my previous post[1]. I have made a chart comparing my proposal to the current draft. As described in the chart, there are some problems with the current draft that cannot be overlooked. I would be happy if you could use it as a reference for your vote. https://docs.google.com/presentation/d/1azfHu93NCm5M9KUbpbtRze7aitvpBAj9SxhpvHe877M In addition, Mr. Richard Barnes also pointed out on the JOSE WG mailing list that it is incorrect to use COSE_Key to represent encapsulated keys[2]. I have the same opinion. As I mentioned repeatedly, the encoding format of the recipient public key and the encapsulated key (ephemeral sender's public key) should be considered separately. The former should be able to be expressed with COSE_Key, but the latter should not. Best regards, Daisuke [1] https://mailarchive.ietf.org/arch/msg/cose/ZY5v7jJr4SxHGIbeA3dgLC6eZDg/ [2] https://mailarchive.ietf.org/arch/msg/jose/IKIR_XusfHD26ewqZSt5ad2WUc8/ 2022年9月23日(金) 2:09 Mike Jones <[email protected]<mailto:[email protected]>>: As discussed at IETF 114, the HPKE draft uses the COSE_Key public key representation. The authors described that Ilari Liusvaara had proposed using a different public key representation, which is detailed in Slide 2 of https://datatracker.ietf.org/meeting/114/materials/slides-114-cose-cose-hpke-00. As recorded in the minutes<https://datatracker.ietf.org/doc/minutes-114-cose/>, consensus during the meeting appeared to be in favor of continuing to use COSE_Key. This note initiates a consensus call by the chairs on the topic of what public key format the COSE HPKE specification will use. Working group members are requested to express their preferences within two weeks of this note (by Thursday, September 6th) for either: 1. Continuing to use COSE_Key 2. Using the different format proposed by Ilari Liusvaara 3. Other (please describe in sufficient detail to enable its specification) Thank you, -- Mike (for the COSE chairs) _______________________________________________ COSE mailing list [email protected]<mailto:[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. 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
