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]
