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]
