Daisuke, Thank you for your reply and the link to the deck.
Your proposal on slide 4 makes your argument very clear. Inline: On Mon, Sep 26, 2022 at 5:35 PM AJITOMI Daisuke <[email protected]> wrote: > 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. > I agree regarding encapsulated keys, disagree regarding serialized public keys or private keys. This is based on my limited understanding, and this comment: https://mailarchive.ietf.org/arch/msg/jose/IKIR_XusfHD26ewqZSt5ad2WUc8 <https://mailarchive.ietf.org/arch/msg/jose/IKIR_XusfHD26ewqZSt5ad2WUc8/> I understand the chairs to be asking this question, as well.... and it maps to your proposal on slide 4. > 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? > To be clear, I don't... in the examples I tried to show the 2 examples based on the comment above. I was trying to sketch your proposal as "Case 1"... but using JSON syntax seems to have created more confusion than helped. > Additionally, please tell me why you can ignore the five shortcomings I > mentioned on my slide. > > https://docs.google.com/presentation/d/1azfHu93NCm5M9KUbpbtRze7aitvpBAj9SxhpvHe877M > > >From your slides: 1) Will the addition of a new HPKE algorithm cause any changes to the specifications and existing implementations on the COSE side? For the current draft (-02), you said: Yes. Whenever a new cipher suite is added to HPKE, it is necessary to develop a mapping specification for COSE_Key (including alg/crv value registration to IANA) and implement an additional enc->COSE_Key conversion process in existing many COSE libraries. I agree the answer is currently Yes. Your proposal says No. I think when you generate a new key pair for use with HPKE, you should set an alg value for use at that time, and not change it. This means when new alg values are created, new keys are created, and regististries must be updated before these keys can be understood. 2) Can HPKE cipher suites be negotiated dynamically and flexibly between a recipient and a sender? For the current draft (-02), you said: No. KDF cannot be negotiated. In the current draft, acceptable combinations of KEM and KDF are restricted. This kind of restriction might be acceptable on upper-layer application spec but it is not good for common layer spec. I agree the answer is currently No. I don't have enough expertise to comment on this part of the spec, or your proposal. 3) Is the information sent from a sender to a recipient necessary and sufficient? For the current draft (-02), you said No. kty (and crv) are mandatory in COSE_Key but it’s not necessary for a recipient. Moreover, it’s not sufficient because it does not have an HPKE cipher suite information enough for a recipient to determine a specific HPKE cipher suite chosen by a sender. I believe this last point is where most of the confusion lies. In the case of an encapsulated key, my understanding is that the only "missing necessary requirement" is the HPKE cipher suite. ^ Your proposal defines this as a new `alg`. Is it legal for this `alg` to also show up in a COSE_Key?... This is where the lines are getting blurry. In the case of a serialized public key (epk), my understanding is that if it's a COSE_Key, kty (and crv) are mandatory, but that they may not be necessary, because they can be inferred. The point I am making regarding preference for established key formats, such as JWK/COSE_Key, only applies to this last sentence ^. The position I am advocating for is to continue to support `epk` in a standard format, because I believe that's what most developers with experience would expect. In your proposal you refer to this value as "HPKE Sender Information", where "kty" and "crv" are not required but `alg` is... and the missing values are inferred from the recipient. Your proposal saves bytes, at the cost of introducing a new "epk like" thing. I realize my position "wastes bytes", but in my experience new keys or key like formats are "more expensive" in human terms and complexity. It's also possible I don't know what I am talking about. I am new to HPKE and I am bringing a bunch of assumptions from years of working with JOSE. I hope I have answered your questions, I find the visual examples really helpful when trying to understand the arguments... but I can also see how they might add to the confusion. I consider Daisuke to have provided an example of an alternative approach, but I am not enough of an expert to know if it's sufficient for specification. Similarly Ilari has provided an alternative approach, but I am not enough of an expert to know if it's sufficient for specification. Based on my understanding of their arguments, a new `alg` would NOT need to be registered for new HPKE cipher suites. And therefore new keys would not be bound to a specific HPKE cipher suites, but rather to the family of all HPKE in general... with the details of that binding conveyed via cose headers. This does not map to my intuition looking at the test vectors. https://www.rfc-editor.org/rfc/rfc9180.html#name-test-vectors I would love to hear from the authors of the RFC on this point. Regards, OS 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> >> > -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
