> 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
