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]
