Like Orie - pretty hard on use AKP or something more appropriate This is not elliptic curve stuff
Mike Prorock On Mon, Dec 2, 2024 at 1:55 PM 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] >
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
