My comments were addressed, however, I wonder if we should finish the base HPKE specs before taking on new work.
I noticed the algorithm suite names in this draft are still using the parametric form. Regards, OS On Wed, Jan 15, 2025 at 7:33 AM Michael Prorock <[email protected]> wrote: > I believe my concerns are addressed > > On Tue, Jan 14, 2025, 21:28 Michael Jones <[email protected]> > wrote: > >> Thanks for updating the draft, Tiru. Ilari, Michael, Michael, Orie, and >> Sophie, can you please reply-all to this thread saying whether you believe >> your comments have been addressed or not? >> >> >> >> Thank you, >> >> -- Mike (for the COSE >> chairs) >> >> >> >> *From:* tirumal reddy <[email protected]> >> *Sent:* Thursday, December 12, 2024 5:38 AM >> *To:* [email protected]; Hannes Tschofenig < >> [email protected]> >> *Subject:* Fwd: [COSE] Re: Call for adoption of >> draft-reddy-cose-jose-pqc-hybrid-hpke >> >> >> >> Hi Chairs, >> >> >> >> I have addressed all the comments from the WG for >> draft-reddy-cose-jose-pqc-hybrid-hpke. >> >> Could you consider making a decision on the adoption call now? >> >> >> >> Cheers, >> >> -Tiru >> >> ---------- Forwarded message --------- >> From: *Orie Steele* <[email protected]> >> Date: Wed, 11 Dec 2024 at 20:35 >> Subject: Re: [COSE] Re: Call for adoption of >> draft-reddy-cose-jose-pqc-hybrid-hpke >> To: tirumal reddy <[email protected]> >> Cc: Sophie Schmieg <[email protected]>, Michael Jones < >> [email protected]>, [email protected] <[email protected]> >> >> >> >> Thanks for addressing my comments. >> >> I am happy to contribute some data model examples for JWE and COSE >> Encrypt if I can get some time to code them up. >> >> Modulo the ongoing conversation regarding short names for HPKE >> algorithms, this is looking ready to go from my side. >> >> Regards, >> >> OS >> >> >> >> On Wed, Dec 11, 2024 at 12:30 AM tirumal reddy <[email protected]> wrote: >> >> Illari, Orie, and Mike P, could you please confirm if your comments have >> been addressed in the latest version of the draft >> draft-reddy-cose-jose-pqc-hybrid-hpke >> <https://datatracker.ietf.org/doc/html/draft-reddy-cose-jose-pqc-hybrid-hpke> >> ? >> >> >> >> -Tiru >> >> >> >> On Mon, 9 Dec 2024 at 15:53, tirumal reddy <[email protected]> wrote: >> >> 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/> >> >> >> >> >> -- >> >> >> >> >> *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]
