Hi Hannes,
I made this change to the draft based on a mailing list discussion with
> Ilari. Ilari thought that this information is not needed (it is implicit).
> I had this information explicitly communicated in an earlier version of the
> document.
>
KDF information should not be omitted. I have checked draft-01. Okay, it
does contain KDF information.
In the draft-01, alg value has kem+kdf+aead information.
In this case, since there are currently 4 KEM, 3 KDF, and 3 AEAD algorithms
defined for HPKE,
does this mean that a total of 36 (4*3*3) COSE-HPKE alg values will be
registered in the COSE IANA registry?
If one new AEAD algorithm is added, will 12 (4 KEM * 3 KDF) different
COSE-HPKE alg values be newly registered in the IANA registry?
It is the same thing whether you put it in kty or crv instead of alg. I
think it is very complicated.
My proposal is free from this kind of complexity.
Could you tell me two additional points?
1. Why do you want to use the COSE_Key structure for the encapsulated key?
Please tell me the COSE_Key parameters which you want to use.
- As I mentioned in my previous post[1], in my point of view, none of
the COSE_Key parameters (except for the key itself) in the IANA registry
are required to express an encapsulated key.
2. What are your thoughts on the five issues I mentioned on my slide? I'd
like to know the reason why you can ignore them.
Could you explain what you mean by “not adequately represent the
> information that should be exchanged between a sender and a recipient”?
>
Sorry for the ambiguity. My point was that the KDF information was
missing.
I believe that in an HPKE transaction, the sender needs to tell the
recipient following information:
- the identifier of the receiver's public key = kid
- the encapsulated key
- the HPKE cipher suite information (kem_id, kdf_id, aead_id) negotiated. #
kem_id can be omitted since it is represented by kid.
Regards,
Daisuke
2022年9月27日(火) 17:09 Hannes Tschofenig <[email protected]>:
> Hi Daisuke,
>
>
>
>
>
> - 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.
>
>
>
> I have implemented the code:
>
> - HPKE: https://github.com/Mbed-TLS/mbedtls/pull/5078
> - COSE-HPKE: https://github.com/laurencelundblade/t_cose/pull/75
>
>
>
>
>
> - 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)
>
>
>
> I made this change to the draft based on a mailing list discussion with
> Ilari. Ilari thought that this information is not needed (it is implicit).
> I had this information explicitly communicated in an earlier version of the
> document.
>
>
>
> - 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.
>
> Could you explain what you mean by “not adequately represent the
> information that should be exchanged between a sender and a recipient”?
>
>
>
> Ciao
>
> Hannes
>
>
>
>
>
> Regards,
>
> Daisuke
>
>
>
>
>
> 2022年9月27日(火) 2:08 Hannes Tschofenig <[email protected]>:
>
> 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]>:
>
> 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]> *On Behalf Of *AJITOMI Daisuke
> *Sent:* Friday, September 23, 2022 12:00 AM
> *To:* Mike Jones <[email protected]>
> *Cc:* [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 <Michael.Jones=
> [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]
> 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.
>
> 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
