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]
