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