[COSE] Re: Call for adoption of draft-reddy-cose-jose-pqc-hybrid-hpke

[Orie Steele <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]> 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 <[e-mail]>
>>> 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 <[e-mail]>
>>>> 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 <[e-mail]>
>>>>> 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 <[e-mail]>
>>>>>> 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 <[e-mail]>
>>>>>>> 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 <[e-mail]>
>>>>>>>> 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 <
>>>>>>>>> [e-mail]> 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 <[e-mail]>
>>>>>>>>>> *Sent:* Monday, December 2, 2024 5:29 AM
>>>>>>>>>> *To:* Michael Jones <[e-mail]>
>>>>>>>>>> *Cc:* [e-mail]
>>>>>>>>>> *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 <
>>>>>>>>>> [e-mail]> 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:* [e-mail]
>>>>>>>>>> *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 -- [e-mail]
>>>>>>>>>> To unsubscribe send an email to [e-mail]
>>>>>>>>>>
>>>>>>>>>> _______________________________________________
>>>>>>>>>> COSE mailing list -- [e-mail]
>>>>>>>>>> To unsubscribe send an email to [e-mail]
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> 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 -- [e-mail]
>>>>>> To unsubscribe send an email to [e-mail]
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Sophie Schmieg | Information Security Engineer | ISE Crypto |
>>>>> [e-mail]
>>>>>
>>>>>
>>>>
>>>> --
>>>>
>>>>
>>>> ORIE STEELE
>>>> Chief Technology Officer
>>>> www.transmute.industries
>>>>
>>>> <https://transmute.industries>
>>>>
>>>

-- 


ORIE STEELE
Chief Technology Officer
www.transmute.industries

<https://transmute.industries>