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 <[email protected]>: > > 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 < > [email protected]> 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 <[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. >> _______________________________________________ >> 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
