Re: [COSE] COSE HPKE Public Key Format Consensus Call

[AJITOMI Daisuke <[e-mail]>]

Hi Hannes,

I think my proposal would reduce the code size compared to the current
draft (even in case of adding to the existing code) and also reduce the
final output message size.

Let me ask one question.

The current draft does not represent the KDF information that should be
communicated to the recipient; can you tell us how you intend to include
the KDF information in the message?
(This is a concern that correspond to 2) in the comparison chart I shared)

The current draft does not adequately represent the information that should
be exchanged between a sender and a recipient in HPKE, and I don't think it
is comparable to my proposal in the first place.
Please let us know how you handle KDF information.

Regards,
Daisuke


2022年9月27日(火) 2:08 Hannes Tschofenig <[e-mail]>:

> 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 <[e-mail]> *On Behalf Of * AJITOMI Daisuke
> *Sent:* Monday, September 26, 2022 1:57 PM
> *To:* Hannes Tschofenig <[e-mail]>; [e-mail]
> *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 <[e-mail]>:
>
> 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 <[e-mail]> *On Behalf Of *AJITOMI Daisuke
> *Sent:* Friday, September 23, 2022 12:00 AM
> *To:* Mike Jones <Michael.Jones=[e-mail]>
> *Cc:* [e-mail]
> *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 <Michael.Jones=
> [e-mail]>:
>
> 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
> [e-mail]
> 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.
>