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>
>
_______________________________________________
COSE mailing list -- [email protected]
To unsubscribe send an email to [email protected]
