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

[AJITOMI Daisuke <[e-mail]>]

Hi Orie,

> I would expect ANY new 'alg' values to have some mapping to JWK / CWK.

As Ilari mentioned, this is false for the encapsulated key in the first
place but I'd like to know why the encapsulated key should be mapped to
JWK/CWK.

Why do you want to encode encapsulated keys to JWK/COSE_Key in spite of the
fact that the encapsulated key (NOT recipient's public key) is generated
and consumed inside the COSE-HPKE process and any applications don't need
to know the format and don't need to handle the format directly?

Additionally, please tell me why you can ignore the five shortcomings I
mentioned on my slide.
https://docs.google.com/presentation/d/1azfHu93NCm5M9KUbpbtRze7aitvpBAj9SxhpvHe877M

Regards,
Daisuke

2022年9月27日(火) 3:05 Orie Steele <[e-mail]>:

> > PQC public key encodings in COSE and then again in HPKE?
> > Then, we have even more encodings of the same information.
>
> This is also my concern... But noting,
> https://datatracker.ietf.org/doc/draft-prorock-cose-post-quantum-signatures/
> does not cover any relationship to HPKE...
> We remained confused by the guidance being shared regarding COSE_Key and
> registry requirements.
>
> I would expect ANY new 'alg' values to have some mapping to JWK / CWK.
>
> And for some (new) keys to support multiple algorithms in the future, for
> example:
>
> kty: EC      // if new stuff here or
> crv: P-256 // new stuff here
> alg: ES256 | ECDH-ES+A256KW // then new stuff here as well.
>
> IMO, keys control algorithms... not the other way round.
>
> Keys are generated for a purpose (use with an algorithm).
>
> It's fine for an algorithm to produce intermediate structures, and require
> their specific processing... but if one of those structures is a key, such
> as in JOSE the use of epk.
>
> https://www.rfc-editor.org/rfc/rfc7518.html#section-4.6.1.1
>
> Then this structure needs its terms registered properly.
>
> I have heard some folks say that HPKE produces a structure which is like
> `epk` but IS NOT a "standard key format (COSE_Key)"...
> and therefore no registry update is needed to support it...  *"opaque
> byte strings to preserve agility with regard to the KEM"*
>
> I have also heard folks say that HPKE produces a structure that is like
> `epk` and that IS a "standard key format (COSE_Key)"...
> and that therefore a new registry update is necessary due to the need to
> signal new `alg` values in that key format... *"In DHKEM, the
> encapsulated value is a serialized public key"*
>
> I find that examples help here...  in JOSE:
>
> Example JWE Header:
>
> {
>   *"alg": "ECDH-ES+A256KW",*
>   "enc": "A256GCM",
>   "epk": {
>     "x": "5cxzlgYyEspHzAhIWtnPDSZqzhWGUpRyDJ5M2EKg-D8",
>     "crv": "P-256",
>     "kty": "EC",
>     "y": "ECmJDhcuHOYtVQUukO8uxOErqcYk5ibyxqt-5IKXTcY"
>   }
> }
>
> Example JWK:
>
> {
>   "kid":
> "urn:ietf:params:oauth:jwk-thumbprint:sha-256:Dg1hH8e81xxGq0jaXxTl2dbyiabZAZtH0qDLRsT1VhA",
>   "kty": "EC",
>   "crv": "P-256",
>  * "alg": "ECDH-ES+A256KW",*
>   "key_ops": [
>     "decrypt"
>   ],
>   ...
> }
>
> From:
> https://mailarchive.ietf.org/arch/msg/jose/IKIR_XusfHD26ewqZSt5ad2WUc8/
>
> I am hearing that something like this is expected:
>
> Case 0:
>
>
> https://www.rfc-editor.org/rfc/rfc9180.html#name-dhkemp-256-hkdf-sha256-hkdf-
>
> JWK:
>
> {
>   "kid":
> "urn:ietf:params:oauth:jwk-thumbprint:sha-256:Dg1hH8e81xxGq0jaXxTl2dbyiabZAZtH0qDLRsT1VhA",
>   "kty": ...
>   "alg": " ** DHKEM ** +A256KW",
>   "key_ops": [
>     "decrypt"
>   ],
>   ...
> }
>
> JWE Header:
>
> {
>   "alg": " ** DHKEM ** +A256KW", // registry update for COSE Key required
>   "enc": "A256GCM",
>   "epk": { COSE_Key, JOSE_Key }
> }
>
> But also:
>
> Case 1:
>
> ( Where is this in the RFC?, how do I refer to this case by name? )
>
> JWK:
>
> {
>   "kid":
> "urn:ietf:params:oauth:jwk-thumbprint:sha-256:Dg1hH8e81xxGq0jaXxTl2dbyiabZAZtH0qDLRsT1VhA",
>   "kty": ...
>   "alg": " ** **KEM** ** +A256KW",  // registry update for COSE Key
> required
>   "key_ops": [
>     "decrypt"
>   ],
>   ...
> }
>
> JWE Header
> {
>   "alg": " ** KEM ** +A256KW", // registry update for COSE Key required
>   "enc": "A256GCM",
>   "kem": ** opaque byte string * *// registry update for HPKE required
> }
>
>
> Hopefully these examples are triggering enough to get a clearer proposal,
> especially regarding case 1 which I still don't understand well enough.
>
> My "Case 0" matches this proposal:
>
> > 1.  Continuing to use COSE_Key
>
> ^ I support this proposal.
>
> Regards,
>
> OS
>
> On Mon, Sep 26, 2022 at 12:08 PM Hannes Tschofenig <
> [e-mail]> wrote:
>
>> 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.
>> _______________________________________________
>> COSE mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/cose
>>
>
>
> --
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries>
>