Tirumal, Thanks for addressing the feedback. I support adoption. - Mike
On Thu, Dec 12, 2024, 06:35 tirumal reddy <[email protected]> wrote: > Thanks Orie for your feedback. The data model examples for JWE and COSE > Encrypt would indeed be a fantastic addition. Please feel free to share > them whenever you have the time to code them up. > > I’ll keep an eye on the ongoing conversation around short names for HPKE > algorithms in JOSE and update the draft as needed. > > -Tiru > > On Wed, 11 Dec 2024 at 20:35, Orie Steele <[email protected]> > wrote: > >> 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> >> > _______________________________________________ > 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]
