Hi all, I have published a revised draft ( https://www.ietf.org/archive/id/draft-reddy-cose-jose-pqc-hybrid-hpke-05.html), which addresses all comments raised, particularly from Orie and Ilari. The draft appears ready for adoption.
Cheers, -Tiru On Fri, 6 Dec 2024 at 15:36, tirumal reddy <[email protected]> wrote: > Hi Orie, > > I raised a PR https://github.com/tireddy2/Hybrid-KEM-with-COSE-JOSE/pulls > to use "AKP". > > Cheers, > -Tiru > > On Thu, 5 Dec 2024 at 04:05, Orie Steele <[email protected]> > wrote: > >> Changing "crv" is indeed not possible at this point.... but we are not >> required to use "crv" to express pqc or hybrid keys. >> >> The document that enables an "alg" to be used in a message can also >> specify which "kty" and other parameters are required to be present when >> that alg is expressed in a key. >> >> We are comparing: >> >> ### Option A >> >> const jwk = { >> kty: "AKP", // mandatory >> alg: "X-Wing", // mandatory >> pub: "4iNrNajCSz...tmrrIzQSQQO9lNA", // mandatory >> priv: "f5wrpOiP...rPpm7yY", // mandatory >> }; >> >> ### Option B >> >> const jwk = { >> kty: "OKP", // mandatory >> crv: "X-Wing", // mandatory >> alg: "X-Wing", // optional >> x: "4iNrNajCSz...tmrrIzQSQQO9lNA", // mandatory >> d: "f5wrpOiP...rPpm7yY" // mandatory >> }; >> >> I'm saying let's go with Option A. >> >> >> On Wed, Dec 4, 2024 at 4:22 PM Sophie Schmieg <[email protected]> >> wrote: >> >>> I would really like to avoid a reality where someone uses the separate >>> parts of an X-Wing key in their own primitives, that way lies madness and >>> vulnerabilities. COSE should treat hybrids just like any other algorithm, >>> and pretend to not know anything about how the opaque blob of bytes >>> operates. >>> As for unfortunate naming decisions, there is some precedent here, with >>> TLS calling everything a group. Kind of unfortunate and "algorithm >>> parameter" or similar would have been the far better term for it, but I >>> somewhat assume that changing this name at this point is infeasible. (An >>> overly pendadic person might point out though, that Z[X]/(X^256+1)^3 is, as >>> a module of a number field order, by definition still a group, and that >>> Z[X](X^256+1) has Dedekind dimension one, which means that it would be fair >>> to say that at least Spec Z[X]/(X^256+1) is a curve, so we are still >>> talking about a vector bundle over a curve) >>> >>> On Wed, Dec 4, 2024 at 6:25 AM tirumal reddy <[email protected]> wrote: >>> >>>> Thanks Orie for valuable inputs, raise PRs for both the drafts, see >>>> https://github.com/tireddy2/Hybrid-KEM-with-COSE-JOSE/pull/4 >>>> and >>>> https://github.com/ietf-wg-jose/draft-ietf-jose-hpke-encrypt/pull/11. >>>> >>>> On Tue, 3 Dec 2024 at 20:08, Orie Steele <[email protected]> >>>> wrote: >>>> >>>>> Sure, but that is a problem for: >>>>> >>>>> https://datatracker.ietf.org/doc/draft-ietf-cose-hpke/ >>>>> https://datatracker.ietf.org/doc/draft-ietf-jose-hpke-encrypt/ >>>>> >>>>> Consider what the example you gave above means in a pre-hpke world: >>>>> >>>>> { >>>>> "kty": "OKP", >>>>> "crv": "X25519", >>>>> "algorithms": ["ECDH-ES+A128KW", "ECDH-ES+A256KW"], >>>>> "x": "KIWi1p4buN7...N8zkhfF8pGs", >>>>> } >>>>> >>>>> The algorithms in the key are for key establishment / key wrapping... >>>>> not content encryption. >>>>> >>>>> HPKE is adding the idea of enabling "direct integrated encryption". >>>>> ... and in doing so, enabling you to use a key wrapping algorithm >>>>> which is also a content encryption algorithm and which is an hpke aead. >>>>> If that's a bad idea, we are not making it better by adding PQ/T >>>>> hybrids to it, or enabling multiple HPKE suites to be used for the same >>>>> KEM >>>>> key. >>>>> >>>>> https://datatracker.ietf.org/doc/html/rfc9180#name-kem-key-reuse >>>>> >>>>> So while HPKE might allow the same kem key to be used with multiple >>>>> AEADs, there is no reason that JOSE and COSE should allow it... >>>>> *Because this use case is solved for in the 2 layer constructions in >>>>> JOSE and COSE.* >>>>> >>>>> I consider it to be a bad idea to advertise multiple key encryption / >>>>> key wrapping algorithms for a single kem key pair. >>>>> >>>>> Let's look at a complete example of X-Wing in JOSE starting with the >>>>> recipient public key: >>>>> >>>>> { >>>>> "kty": "AKP", >>>>> "kid": >>>>> "urn:ietf:params:oauth:jwk-thumbprint:sha-256:S6AXfdU_6Yfzvu0KDDJb0sFuwnIWPk6LMTErYhPb32s", >>>>> "alg": "HPKE-XWING-SHA256-A256GCM", >>>>> "pub": "KIWi1p4buN7...N8zkhfF8pGs", >>>>> "priv": "i20zlCBQr0...JsShVkf3q4qUc" >>>>> } >>>>> >>>>> ^ such a key can be used for both integrated encryption and 2 key >>>>> encryption in both JOSE and COSE. >>>>> >>>>> You can encrypt directly to this key using A256GCM, >>>>> and indirectly by using HPKE-XWING-SHA256-A256GCM to encrypt a >>>>> content encryption key, and then using any of the algorithms registered >>>>> here: >>>>> >>>>> >>>>> https://www.iana.org/assignments/jose/jose.xhtml#web-signature-encryption-algorithms >>>>> ... that support "enc" ... (ChaCha20Poly1305 is not in this registry btw). >>>>> >>>>> ## Integrated Encryption (X-Wing HPKE JWT) >>>>> >>>>> { >>>>> "protectedHeader": { >>>>> "alg": "HPKE-XWING-SHA256-A256GCM", >>>>> "enc": "dir", >>>>> "kid": " >>>>> urn:ietf:params:oauth:jwk-thumbprint:sha-256:S6AXfdU_6Yfzvu0KDDJb0sFuwnIWPk6LMTErYhPb32s >>>>> " >>>>> }, >>>>> "payload": { >>>>> "urn:example:claim": true, >>>>> "iss": "urn:example:issuer", >>>>> "aud": "urn:example:audience", >>>>> "iat": 1729785491, >>>>> "exp": 1729792691 >>>>> } >>>>> } >>>>> >>>>> ## Key Encryption (Multiple recipients, using the same content >>>>> encryption algorithm) >>>>> >>>>> { >>>>> "protected": "eyJlbmMiOiJBMTI4R0NNIn0", // { "enc" : "A128GCM" } >>>>> "iv": "ZL0HDvZJizA6vyTV", >>>>> "ciphertext": "Oq26x9vppULrGNzCn2j...BgQpgJPchg0eWNmgv4Ozi5I", >>>>> "tag": "ULnlOiJRYfCzM_r5j9sLEQ", >>>>> "aad": "cGF1bCBhdHJlaWRlcw", >>>>> "recipients": [ >>>>> { >>>>> "encrypted_key": "G3HmlpOgA4H...w7svDwUqvNR", >>>>> "header": { >>>>> "kid": "urn:ietf:params:oauth:jwk-thumbprint:sha-256: >>>>> cxQC_lWt22BIjH5AWSLHCZk_f-mU3-W4Ztcu5-ZbwTk", >>>>> "alg": "ECDH-ES+A128KW", >>>>> "epk": { >>>>> "kty": "OKP", >>>>> "crv": "X25519", >>>>> "x": "JnGWSQ90hlt0H7..._Dn_CkLzE", >>>>> } >>>>> } >>>>> }, >>>>> { >>>>> "encrypted_key": "pn6ED0ijngCiWF8...mRF7QarTVfuWj6dw", >>>>> "header": { >>>>> "alg": "HPKE-XWING-SHA256-A256GCM", >>>>> "kid": >>>>> "urn:ietf:params:oauth:jwk-thumbprint:sha-256:S6AXfdU_6Yfzvu0KDDJb0sFuwnIWPk6LMTErYhPb32s", >>>>> "ek": >>>>> "BI41YDnhTTI6jSd7T62rLwzC...X9UXDw_3ylbXTiYWmPXl2fNmr4BeQ" >>>>> } >>>>> } >>>>> ] >>>>> } >>>>> >>>>> Some comments on kem key reuse: >>>>> >>>>> In the example above, assume the X25519 ECDH-ES+A128KW part is to the >>>>> x25519 component of the X-Wing key. >>>>> When a CRQC breaks ECDH-ES, the encrypted content encryption key is >>>>> broken, and the attacker can ignore x-wing completely, and still recover >>>>> the plaintext. >>>>> This remains true when any recipient in a 2 layer uses any of the >>>>> traditional 2 layer algorithms in the JOSE and COSE registries today >>>>> (except for psk stuff mixed into kdfs). >>>>> >>>>> In the case of direct encryption to the x25519 component of an x-wing >>>>> key, the plaintext is also recovered. >>>>> >>>>> The only way to protect against both modes is to use X-Wing for both >>>>> integrated encryption and key encryption and to always use the full x-wing >>>>> algorithm with a given x-wing key, and in the case of multiple recipients, >>>>> to ensure that each recipient is using a PQ key encryption / key wrapping >>>>> algorithm.... because in 2 layer breaking a single recipient encrypted >>>>> content encryption key recovers plaintext. >>>>> >>>>> OS >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Tue, Dec 3, 2024 at 6:57 AM tirumal reddy <[email protected]> >>>>> wrote: >>>>> >>>>>> Thanks Orie for the detailed explanation. I understand your >>>>>> suggestion to use "AKP" instead of "OKP," but "AKP" has limitations, >>>>>> particularly with the HPKE PQ/T scheme. For example, in the HPKE, a >>>>>> single >>>>>> key agreement mechanism can be paired with multiple AEAD algorithms, >>>>>> resulting in unique cryptographic algorithm identifiers. For instance: >>>>>> >>>>>> - HPKE-XWING-SHA256-ChaCha20Poly1305 >>>>>> - HPKE-XWING-SHA256-AES256GCM >>>>>> >>>>>> To address this, the key type "AKP" would need to be extended to >>>>>> accommodate multiple algorithms. A possible JSON representation could >>>>>> look >>>>>> like this: >>>>>> >>>>>> { >>>>>> "kty": "AKP", >>>>>> "kid": "01", >>>>>> "algorithms": [ >>>>>> "HPKE-XWING-SHA256-ChaCha20Poly1305", >>>>>> "HPKE-XWING-SHA256-AES256GCM" >>>>>> ], >>>>>> "key_ops": [ >>>>>> "deriveBits", >>>>>> "wrapKey" >>>>>> ]} >>>>>> >>>>>> -Tiru >>>>>> >>>>>> On Tue, 3 Dec 2024 at 02:25, Orie Steele <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> https://author-tools.ietf.org/iddiff?url1=draft-reddy-cose-jose-pqc-hybrid-hpke-03&url2=draft-reddy-cose-jose-pqc-hybrid-hpke-04&difftype=--hwdiff >>>>>>> >>>>>>> Further comments: >>>>>>> >>>>>>> X-Wing is not an Elliptic Curve. >>>>>>> >>>>>>> X-Wing keys using OKP and (ab)using the "crv" parameter to mean >>>>>>> "curve with parameters + lattice with parameters"... is something I >>>>>>> really hope we can decide not to do. >>>>>>> >>>>>>> As I said in >>>>>>> https://mailarchive.ietf.org/arch/msg/cose/LMh6LpT5aqF5m47dmQ_roWU18eM/ >>>>>>> >>>>>>> It would be nice to agree to use keys for algorithms, and to use AKP >>>>>>> for ML-KEM and ML-DSA, and X-Wing with HPKE, and X-Wing without HPKE... >>>>>>> and >>>>>>> all of this is possible with the use of the AKP key type with fully >>>>>>> specified algorithms. >>>>>>> >>>>>>> >>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-cose-dilithium-04#name-algorithm-key-pair-type >>>>>>> >>>>>>> Obviously I disagree with Ilari on this point. >>>>>>> .... however, I hope we can agree that whatever we do for ML-DSA, it >>>>>>> will work for ML-KEM and X-Wing, and HPKE... or whatever CRFG comes up >>>>>>> with >>>>>>> next. >>>>>>> >>>>>>> *In summary, it's nice that the HPKE algorithms have been added, but >>>>>>> I object to the key representation using OKP.* >>>>>>> >>>>>>> Motivation for my objection to the use of OKP for ML-KEM keys: >>>>>>> >>>>>>> Consider that OKP is commonly considered reserved for "elliptic >>>>>>> curve points", as noted in >>>>>>> https://datatracker.ietf.org/doc/html/rfc8152#section-12.4.2 >>>>>>> >>>>>>> https://www.rfc-editor.org/rfc/rfc8037.html#section-2 >>>>>>> >>>>>>> Note: Do not assume that there is an underlying elliptic curve, >>>>>>> despite the existence of the "crv" and "x" parameters. (For >>>>>>> instance, this key type could be extended to represent >>>>>>> Diffie-Hellman >>>>>>> (DH) algorithms based on hyperelliptic surfaces.) >>>>>>> >>>>>>> It does not matter how many times I read the note above, the >>>>>>> normative MUST says: >>>>>>> >>>>>>> o The parameter "crv" MUST be present and contain the subtype of >>>>>>> the >>>>>>> key (from the "JSON Web Elliptic Curve" registry). >>>>>>> >>>>>>> This means we are required to put things that are not curves in a >>>>>>> registry for curves.... >>>>>>> >>>>>>> If the algorithm param "alg" is not mandatory for an X-Wing key, can >>>>>>> I use the same key for ML-KEM and X25519 and X-Wing? >>>>>>> Do I have to put "alg" in the key, even though it's optional (in >>>>>>> OKP) to signal a safer use pattern? >>>>>>> If I encrypt with X25519 to an X-Wing key that has no "alg" >>>>>>> parameter, what happens?... is it ok, if I use the X25519 component to >>>>>>> decrypt? it works... is this legal? >>>>>>> >>>>>>> { >>>>>>> "kty": "OKP", >>>>>>> "crv": "X-Wing", // not a curve... just means x and d cannot >>>>>>> be validated... unless you know the intended algorithm >>>>>>> "alg": "ECDH-ES+A128KW", // HPKE-XWING-SHA256-AES256GCM >>>>>>> // HPKE-X25519-SHA256-CHACHA20POLY1305 >>>>>>> "x": "KIWi1p4buN7...N8zkhfF8pGs", // 2 public keys >>>>>>> "d": "i20zlCBQr0...JsShVkf3q4qUc" // 2 private keys or a >>>>>>> single seed for both private keys >>>>>>> } >>>>>>> >>>>>>> The thumbprints will be different ... >>>>>>> https://datatracker.ietf.org/doc/html/draft-ietf-cose-key-thumbprint-06#name-octet-key-pair-okp >>>>>>> >>>>>>> Even if the same private key can decrypt messages to each public key >>>>>>> that contains "somewhere (no validation)" the necessary components.... >>>>>>> The thumbprint for a hybrid public key should include the algorithm >>>>>>> used to construct the hybrid, not just the public keys used with any >>>>>>> component algorithms or the hybrid. >>>>>>> >>>>>>> Either we should scrap the AKP concept and use OKP as Ilari >>>>>>> suggested. >>>>>>> ... or we should not use OKP for new "subtype"s... and especially >>>>>>> not for hybrids. >>>>>>> >>>>>>> I don't know if this comment should gate working group adoption, but >>>>>>> it certainly seems it should gate a WGLC for either document that >>>>>>> references ML-KEM / ML-DSA . >>>>>>> Thanks to Russ, Neil and others who gave WGLC feedback on AKP and >>>>>>> ML-DSA for JOSE and COSE, I am tracking your comments here: >>>>>>> https://github.com/cose-wg/draft-ietf-cose-dilithium/issues but >>>>>>> have not yet addressed them. >>>>>>> >>>>>>> Ilari, Hannes and Tiru, please feel free to file a WGLC comment on >>>>>>> the use of AKP in ML-DSA. >>>>>>> >>>>>>> Whatever the outcome, there should be alignment on seeds, private >>>>>>> keys, public keys and algorithms for lattice and hybrid PQC (ML-DSA / >>>>>>> ML-KEM / X-Wing) >>>>>>> >>>>>>> "pub" is better than "x" >>>>>>> >>>>>>> "priv" is better than "d" >>>>>>> >>>>>>> "alg" should have been mandatory in keys, >>>>>>> ... and forbidden in headers ( a ship that has sailed, and can't be >>>>>>> fixed for EC2 / OKP keys, or JWE / COSE Encrypt envelopes )... >>>>>>> >>>>>>> *...things that are not elliptic curves do not belong in a >>>>>>> registry for elliptic curves...* >>>>>>> >>>>>>> I will die on these hills. If I'm in the rough, it would be good to >>>>>>> know. >>>>>>> >>>>>>> OS >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Mon, Dec 2, 2024 at 11:11 AM Michael Jones < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Ilari, Orie, and Mike P., do you believe that your comments on the >>>>>>>> previous draft have been addressed in this one? If not, what further >>>>>>>> changes would you suggest? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks all, >>>>>>>> >>>>>>>> -- >>>>>>>> Mike >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *From:* tirumal reddy <[email protected]> >>>>>>>> *Sent:* Monday, December 2, 2024 5:29 AM >>>>>>>> *To:* Michael Jones <[email protected]> >>>>>>>> *Cc:* [email protected] >>>>>>>> *Subject:* Re: [COSE] Re: Call for adoption of >>>>>>>> draft-reddy-cose-jose-pqc-hybrid-hpke >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The revised draft >>>>>>>> https://www.ietf.org/archive/id/draft-reddy-cose-jose-pqc-hybrid-hpke-04.html >>>>>>>> addresses all the comments raised during the WG adoption call. >>>>>>>> Regarding >>>>>>>> Michael's comment on the terms 'traditional' and 'Post-Quantum,' this >>>>>>>> issue >>>>>>>> has been discussed in the PQUIP WG. However, no decision has been made >>>>>>>> to >>>>>>>> change the terminology, and this issue is beyond the scope of this >>>>>>>> document >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -Tiru >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sat, 30 Nov 2024 at 22:42, Michael Jones < >>>>>>>> [email protected]> wrote: >>>>>>>> >>>>>>>> Only two replies to the call for adoption clearly stated that they >>>>>>>> favored adoption. Whereas more messages were sent than that with >>>>>>>> critiques >>>>>>>> of the draft. Therefore, the draft is not adopted in its present form. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> The chairs suggest that the authors update the specification to >>>>>>>> address the feedback from Ilari, Orie, Mike P., and Michael R. and >>>>>>>> publish >>>>>>>> a new draft, and then ask for feedback on the revised draft on the >>>>>>>> mailing >>>>>>>> list. Following that, we can consider a call for adoption of the >>>>>>>> revised >>>>>>>> draft. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> For >>>>>>>> the chairs, >>>>>>>> >>>>>>>> -- >>>>>>>> Mike >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *From:* Michael Jones >>>>>>>> *Sent:* Friday, November 8, 2024 7:04 AM >>>>>>>> *To:* [email protected] >>>>>>>> *Subject:* Call for adoption of >>>>>>>> draft-reddy-cose-jose-pqc-hybrid-hpke >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Per discussions at the IETF 121 COSE working group meeting, this >>>>>>>> note starts a two-week call for adoption of the PQ/T Hybrid KEM: HPKE >>>>>>>> with >>>>>>>> JOSE/COSE specification. Please let us know whether you are in favor >>>>>>>> of >>>>>>>> adoption or not by Friday, November 22, 2024. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thank you, >>>>>>>> >>>>>>>> -- >>>>>>>> Mike & Ivo >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> COSE mailing list -- [email protected] >>>>>>>> To unsubscribe send an email to [email protected] >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> COSE mailing list -- [email protected] >>>>>>>> To unsubscribe send an email to [email protected] >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> >>>>>>> >>>>>>> ORIE STEELE >>>>>>> Chief Technology Officer >>>>>>> www.transmute.industries >>>>>>> >>>>>>> <https://transmute.industries> >>>>>>> >>>>>> >>>>> >>>>> -- >>>>> >>>>> >>>>> ORIE STEELE >>>>> Chief Technology Officer >>>>> www.transmute.industries >>>>> >>>>> <https://transmute.industries> >>>>> >>>> _______________________________________________ >>>> COSE mailing list -- [email protected] >>>> To unsubscribe send an email to [email protected] >>>> >>> >>> >>> -- >>> >>> Sophie Schmieg | Information Security Engineer | ISE Crypto | >>> [email protected] >>> >>> >> >> -- >> >> >> ORIE STEELE >> Chief Technology Officer >> www.transmute.industries >> >> <https://transmute.industries> >> >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
