[openpgp] Re: [EXTERNAL] Re: draft-ietf-openpgp-nist-b p-comp: add Category-5/P-384 combinations
NGG <[email protected]> Tue, 7 Jul 2026 16:29:38 +0200
| Newsgroups | gmane.ietf.openpgp |
|---|---|
| Message-ID | <CA+z5aXcbKtLEXimP2a+VNoQtB2=6U1X+WwPrfAw84tcCAucPfg@mail.gmail.com> |
--===============0478771040097885020== Content-Type: multipart/alternative; boundary="0000000000002b80160656063925" --0000000000002b80160656063925 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Quynh, Falko, Thanks, that clarification helps. My intention in raising this was mainly to see whether people in the WG, or implementers, see deployment value in these combinations. I do not personally have an immediate hard requirement for them. The case I had in mind is a product or library using OpenPGP that wants to choose a default PQ/T OpenPGP key type for broad deployment. For such a default, category-5 ML-KEM / ML-DSA seems like the conservative choice for CNSA 2.0 and similar future high-assurance PQ requirements. At the same time, P-384 seems to be the classical curve that is already profiled in a number of existing high-assurance environments, while P-521 is often not profiled there. So the reason this combination looks useful to me is that it could be a good fit for both sides: category-5 ML-* for the PQ part, and P-384 for compatibility with existing environments that already profile P-384 but not P-521. The references below are not OpenPGP profiles, and most are PKI/X.509/TLS/credential-related, so I am not claiming that they directly impose an OpenPGP requirement. They are just examples of the kind of surrounding policy environment where P-384 is familiar and accepted, but P-521 is not part of the profile. References where P-384 is profiled and P-521 is not: - CNSA 1.0 TLS profile / RFC 9151: https://www.rfc-editor.org/rfc/rfc9151.html <https://www.rfc-editor.org/rfc/rfc9151.html?utm_source=3Dchatgpt.com> - NIST SP 800-78-5 / PIV algorithms and key sizes: https://csrc.nist.gov/pubs/sp/800/78/5/final <https://csrc.nist.gov/pubs/sp/800/78/5/final?utm_source=3Dchatgpt.com> - U.S. Federal PKI Common Certificate Profiles: https://www.idmanagement.gov/docs/fpki-x509-cert-profile-common.pdf <https://www.idmanagement.gov/docs/fpki-x509-cert-profile-common.pdf?utm= _source=3Dchatgpt.com> - U.S. Federal Public Trust TLS PKI Certificate Policy: https://www.idmanagement.gov/docs/us-federal-public-trust-tls-cp.pdf <https://www.idmanagement.gov/docs/us-federal-public-trust-tls-cp.pdf?ut= m_source=3Dchatgpt.com> - DoD NIPRNet Certificate and CRL Profiles: https://dl.dod.cyber.mil/wp-content/uploads/pki-pke/pdf/unclass-dod_pki_= nipr_cert_profiles.pdf <https://dl.dod.cyber.mil/wp-content/uploads/pki-pke/pdf/unclass-dod_pki= _nipr_cert_profiles.pdf?utm_source=3Dchatgpt.com> - DoD External Certification Authority Certificate Policy: https://dl.dod.cyber.mil/wp-content/uploads/eca/pdf/unclass-eca_cp_v4-7_= final_signed.pdf <https://dl.dod.cyber.mil/wp-content/uploads/eca/pdf/unclass-eca_cp_v4-7= _final_signed.pdf?utm_source=3Dchatgpt.com> - NATO NISP Baseline 16, including FMN-related material: https://nhqc3s.hq.nato.int/apps/nisp/NISP_Baseline_16_Catalogue_5SEP2024= _enclosure_only.pdf <https://nhqc3s.hq.nato.int/apps/nisp/NISP_Baseline_16_Catalogue_5SEP202= 4_enclosure_only.pdf?utm_source=3Dchatgpt.com> Best regards, Gergely Falko Strenzke <[email protected]> ezt =C3=ADrta (id=C5=91pont: 2026. j= =C3=BAl. 7., K, 14:58): > Indeed, it's possible to write a draft and then have code points assigned > via the "specification required" rule for assigning code points. An RFC i= s > not necessary for assigning code points. WG approval is also not required= . > > Falko > > On Tue, 2026-07-07 at 10:40 +0000, Dang, Quynh H. (Fed) wrote: > > Hi Gergely, One thing I know you can do is to write a short draft > specifying the options that you need/want, then ask the working group to > adopt it. If the working group does not adopt it, you could ask for only > code points (I don=E2=80=99t know if the working group would approve that= ). > Regards, Quynh. *From:* NGG [email protected] > *Sent:* Monday, July 6, 2026 11:05 AM > *To:* Falko Strenzke [email protected] > *Cc:* [email protected] > *Subject:* [EXTERNAL] [openpgp] Re: draft-ietf-openpgp-nist-bp-comp: add > Category-5/P-384 combinations > > You don't often get email from [email protected]. Learn why > this is important <https://aka.ms/LearnAboutSenderIdentification> > > Hello Falko, > > Thanks for the question. I did not mean that any single one of the > existing profiles requires both hybrid use and category-5 ML-* alone. My > point is interoperability across profiles: some environments allow P-384 > but not P-521, while other requirements may call for category-5 ML-*. > Implementations may need one standardized hybrid option that works across > as many such environments as possible. So the goal is not to satisfy a > single profile with one algorithm choice, but to define an optional > P-384/category-5 combination that is broadly usable across multiple > profiles and avoids private, non-standard combinations. Best regards, > Gergely > > Falko Strenzke <[email protected]> ezt =C3=ADrta (id=C5=91pont: 202= 6. j=C3=BAl. > 6., H, 16:35): > > Hi Gergely, > > > > On Sat, 2026-06-20 at 22:56 +0200, NGG wrote: > > Hello OpenPGP WG, > > I would like to suggest adding the following optional combinations > to draft-ietf-openpgp-nist-bp-comp: > > - ML-KEM-1024+ECDH-NIST-P-384 > - ML-DSA-87+ECDSA-NIST-P-384 > > The current draft pairs the category-5 ML-* parameter sets only > with P-521, while P-384 is paired with category-3. > > The motivation is compliance interoperability. Some deployed > profiles, including CNSA 1.0 and NATO FMN certificate profiles, admit P-3= 84 > but not P-521. Separately, other policies or deployment requirements may > call for the category-5 ML-* parameter sets. > > What requirements of profiles are you exactly referring to? CNSA does not > require multi-algorithm at all, so for this purpose the security level of > the traditional component should not matter. In fact it could simply be > ignored for the signature at least. > > > > Falko > > These are not necessarily requirements imposed by the same profile, > but software may need to operate across several such environments. > > Standardized P-384/category-5 combinations would provide a > useful intersection. > > There is already relevant IETF precedent: > > - The TLS ECDHE-MLKEM specification defines SecP384r1MLKEM1024. > - The LAMPS composite-signature specification defines > id-MLDSA87-ECDSA-P384-SHA512. > > These combinations could be added alongside the existing P-521 > variants, without changing or replacing them. > > Would the WG consider adding them? > > Best regards, Gergely Nagy > > ------------------------------ > > openpgp mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > > > > > > > ``` > -- ``` > MTG AG > > > > Dr. Falko Strenzke > > > > > > > > Phone: +49 6151 8000 24 > > > > E-Mail: [ > > [email protected]](mailto:[email protected]) > > > > Web: [mtg.de](http://mtg.de/) > > > > > > > > MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany > > > > Commercial register: HRB 8901 > > > > Register Court: Amtsgericht Darmstadt > > > > Management Board: J=C3=BCrgen Ruf (CEO), Tamer Kemer=C3=B6z > > > > Chairman of the Supervisory Board: Dr. Thomas Milde > > > > > > > > This email may contain confidential and/or privileged information. If= you are not the correct recipient or have received this email in error, > > > > please inform the sender immediately and delete this email.Unauthoris= ed copying or distribution of this email is not permitted. > > > > > > > > Data protection information: Privacy policy > > > > > > > > > > > > > > > > > > > > -- > MTG AG > Dr. Falko Strenzke > > Phone: +49 6151 8000 24 > E-Mail: [email protected] > Web: mtg.de > > MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany > Commercial register: HRB 8901 > Register Court: Amtsgericht Darmstadt > Management Board: J=C3=BCrgen Ruf (CEO), Tamer Kemer=C3=B6z > Chairman of the Supervisory Board: Dr. Thomas Milde > > This email may contain confidential and/or privileged information. If you > are not the correct recipient or have received this email in error, > please inform the sender immediately and delete this email.Unauthorised > copying or distribution of this email is not permitted. > > Data protection information: Privacy policy > > --0000000000002b80160656063925 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><p class=3D"gmail-PDq2pG_selectionAnchorContainer">Hi Quyn= h, Falko,<span aria-hidden=3D"true" class=3D"gmail-PDq2pG_selectionAnchor">= </span></p> <p>Thanks, that clarification helps.</p> <p>My intention in raising this was mainly to see whether people in the WG,= or implementers, see deployment value in these combinations. I do not pers= onally have an immediate hard requirement for them.</p> <p>The case I had in mind is a product or library using OpenPGP that wants = to choose a default PQ/T OpenPGP key type for broad deployment.</p> <p>For such a default, category-5 ML-KEM / ML-DSA seems like the conservati= ve choice for CNSA 2.0 and similar future high-assurance PQ requirements. A= t the same time, P-384 seems to be the classical curve that is already prof= iled in a number of existing high-assurance environments, while P-521 is of= ten not profiled there.</p> <p>So the reason this combination looks useful to me is that it could be a = good fit for both sides: category-5 ML-* for the PQ part, and P-384 for com= patibility with existing environments that already profile P-384 but not P-= 521.</p> <p>The references below are not OpenPGP profiles, and most are PKI/X.509/TL= S/credential-related, so I am not claiming that they directly impose an Ope= nPGP requirement. They are just examples of the kind of surrounding policy = environment where P-384 is familiar and accepted, but P-521 is not part of = the profile.</p> <p>References where P-384 is profiled and P-521 is not:</p> <ul> <li> CNSA 1.0 TLS profile / RFC 9151:<br> <a rel=3D"noopener" class=3D"gmail-decorated-link" href=3D"https://www.rfc-= editor.org/rfc/rfc9151.html?utm_source=3Dchatgpt.com">https://www.rfc-edito= r.org/rfc/rfc9151.html</a> </li> <li> NIST SP 800-78-5 / PIV algorithms and key sizes:<br> <a rel=3D"noopener" class=3D"gmail-decorated-link" href=3D"https://csrc.nis= t.gov/pubs/sp/800/78/5/final?utm_source=3Dchatgpt.com">https://csrc.nist.go= v/pubs/sp/800/78/5/final</a> </li> <li> U.S. Federal PKI Common Certificate Profiles:<br> <a rel=3D"noopener" class=3D"gmail-decorated-link" href=3D"https://www.idma= nagement.gov/docs/fpki-x509-cert-profile-common.pdf?utm_source=3Dchatgpt.co= m">https://www.idmanagement.gov/docs/fpki-x509-cert-profile-common.pdf</a> </li> <li> U.S. Federal Public Trust TLS PKI Certificate Policy:<br> <a rel=3D"noopener" class=3D"gmail-decorated-link" href=3D"https://www.idma= nagement.gov/docs/us-federal-public-trust-tls-cp.pdf?utm_source=3Dchatgpt.c= om">https://www.idmanagement.gov/docs/us-federal-public-trust-tls-cp.pdf</a= > </li> <li> DoD NIPRNet Certificate and CRL Profiles:<br> <a rel=3D"noopener" class=3D"gmail-decorated-link" href=3D"https://dl.dod.c= yber.mil/wp-content/uploads/pki-pke/pdf/unclass-dod_pki_nipr_cert_profiles.= pdf?utm_source=3Dchatgpt.com">https://dl.dod.cyber.mil/wp-content/uploads/p= ki-pke/pdf/unclass-dod_pki_nipr_cert_profiles.pdf</a> </li> <li> DoD External Certification Authority Certificate Policy:<br> <a rel=3D"noopener" class=3D"gmail-decorated-link" href=3D"https://dl.dod.c= yber.mil/wp-content/uploads/eca/pdf/unclass-eca_cp_v4-7_final_signed.pdf?ut= m_source=3Dchatgpt.com">https://dl.dod.cyber.mil/wp-content/uploads/eca/pdf= /unclass-eca_cp_v4-7_final_signed.pdf</a> </li> <li> NATO NISP Baseline 16, including FMN-related material:<br> <a rel=3D"noopener" class=3D"gmail-decorated-link" href=3D"https://nhqc3s.h= q.nato.int/apps/nisp/NISP_Baseline_16_Catalogue_5SEP2024_enclosure_only.pdf= ?utm_source=3Dchatgpt.com">https://nhqc3s.hq.nato.int/apps/nisp/NISP_Baseli= ne_16_Catalogue_5SEP2024_enclosure_only.pdf</a> </li> </ul> <p>Best regards,<br> Gergely</p></div><br><div class=3D"gmail_quote gmail_quote_container"><div = dir=3D"ltr" class=3D"gmail_attr">Falko Strenzke <<a href=3D"mailto:falko= [email protected]">[email protected]</a>> ezt =C3=ADrta (id=C5=91pont= : 2026. j=C3=BAl. 7., K, 14:58):<br></div><blockquote class=3D"gmail_quote"= style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);p= adding-left:1ex"><p>Indeed, it's possible to write a draft and then hav= e code points assigned via the "specification required" rule for = assigning code points. An RFC is not necessary for assigning code points. W= G approval is also not required.</p> <p>Falko</p> <p>On Tue, 2026-07-07 at 10:40 +0000, Dang, Quynh H. (Fed) wrote:</p> <blockquote type=3D"cite"> <p>Hi Gergely, =C2=A0 One thing I know you can do is to write a short draft specifying the option= s that you need/want, then ask the working group to adopt it.=C2=A0 If the = working group does not adopt it, you could ask for only code points (I don= =E2=80=99t know if the working group would approve that). =C2=A0 Regards, Quynh. =C2=A0 <strong>From:</strong> NGG <a href=3D"mailto:[email protected]"= target=3D"_blank">[email protected]</a><br> <strong>Sent:</strong> Monday, July 6, 2026 11:05 AM<br> <strong>To:</strong> Falko Strenzke <a href=3D"mailto:[email protected]= " target=3D"_blank">[email protected]</a><br> <strong>Cc:</strong> <a href=3D"mailto:[email protected]" target=3D"_blank">= [email protected]</a><br> <strong>Subject:</strong> [EXTERNAL] [openpgp] Re: draft-ietf-openpgp-nist-= bp-comp: add Category-5/P-384 combinations</p> <p>=C2=A0 You don't often get email from <a href=3D"mailto:[email protected]= etf.org" target=3D"_blank">[email protected]</a>. <a href=3D"ht= tps://aka.ms/LearnAboutSenderIdentification" target=3D"_blank"> Learn why this is important</a></p> <pre><code> Hello Falko, </code></pre> <p>Thanks for the question. I did not mean that any single one of the existing profiles requires both h= ybrid use and category-5 ML-* alone. My point is interoperability across profiles: some environments allow P-384= but not P-521, while other requirements may call for category-5 ML-*. Impl= ementations may need one standardized hybrid option that works across as ma= ny such environments as possible. So the goal is not to satisfy a single profile with one algorithm choice, b= ut to define an optional P-384/category-5 combination that is broadly usabl= e across multiple profiles and avoids private, non-standard combinations. Best regards,<br> Gergely</p> <p>=C2=A0 Falko Strenzke <<a href=3D"mailto:[email protected]" target=3D"_blan= k">[email protected]</a>> ezt =C3=ADrta (id=C5=91pont: 2026. j=C3=BA= l. 6., H, 16:35):</p> <blockquote type=3D"cite"> <pre><code>Hi Gergely, </code></pre> <p>=C2=A0</p> <p>On Sat, 2026-06-20 at 22:56 +0200, NGG wrote:</p> <blockquote type=3D"cite"> <p>Hello OpenPGP WG,</p> <p>I would like to suggest adding the following optional combinations to=C2= =A0draft-ietf-openpgp-nist-bp-comp:</p> <ul> <li>ML-KEM-1024+ECDH-NIST-P-384</li> <li>ML-DSA-87+ECDSA-NIST-P-384</li> </ul> <p>The current draft pairs the category-5 ML-* parameter sets only with=C2= =A0P-521, while P-384 is paired with category-3.</p> <p>The motivation is compliance interoperability. Some deployed profiles,=C2=A0including CNSA 1.0 and NATO FMN certificate pr= ofiles,=C2=A0admit P-384 but not P-521. Separately, other policies or deployment requirements=C2=A0may call for the= category-5 ML-* parameter sets.</p> </blockquote> <p>What requirements of profiles are you exactly referring to? CNSA does no= t require multi-algorithm at all, so for this purpose the security level of= the traditional component should not matter. In fact it could simply be ig= nored for the signature at least.</p> <p>=C2=A0</p> <p>Falko</p> <blockquote type=3D"cite"> <p>These are not necessarily requirements imposed by the same profile, but= =C2=A0software may need to operate across several such environments.</p> <p>Standardized P-384/category-5 combinations would provide a useful=C2=A0i= ntersection.</p> <p>There is already relevant IETF precedent:</p> <ul> <li>The TLS ECDHE-MLKEM specification defines SecP384r1MLKEM1024.</li> <li>The LAMPS composite-signature specification defines id-MLDSA87-ECDSA-P3= 84-SHA512.</li> </ul> <p>These combinations could be added alongside the existing P-521 variants,= =C2=A0without changing or replacing them.</p> <p>Would the WG consider adding them?</p> <p>Best regards, Gergely Nagy</p> <pre><code></code></pre> </blockquote> </blockquote> <hr> <pre><code></code></pre> <p>openpgp mailing list -- <a href=3D"mailto:[email protected]" target=3D"_b= lank">[email protected]</a></p> <pre><code></code></pre> <p>To unsubscribe send an email to <a href=3D"mailto:[email protected]= " target=3D"_blank">[email protected]</a></p> <pre><code>=20 > =C2=A0 > =20 > ``` -- ``` MTG AG > =20 > Dr. Falko Strenzke > =20 > =C2=A0 > =20 > Phone: +49 6151 8000 24 > =20 > E-Mail: [ > <a href=3D"mailto:[email protected]" target=3D"_blank">falko.stren= [email protected]</a>](mailto:<a href=3D"mailto:[email protected]" target=3D"_= blank">[email protected]</a>) > =20 > Web: [<a href=3D"http://mtg.de" target=3D"_blank">mtg.de</a>](<a hre= f=3D"http://mtg.de/" target=3D"_blank">http://mtg.de/</a>) > =20 > =C2=A0 > =20 > MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany > =20 > Commercial register: HRB 8901 > =20 > Register Court: Amtsgericht Darmstadt > =20 > Management Board: J=C3=BCrgen Ruf (CEO), Tamer Kemer=C3=B6z > =20 > Chairman of the Supervisory Board: Dr. Thomas Milde > =20 > =C2=A0 > =20 > This email may contain confidential and/or privileged information. I= f you are not the correct recipient or have received this email in error, > =20 > please inform the sender immediately and delete this email.Unauthori= sed copying or distribution of this email is not permitted. > =20 > =C2=A0 > =20 > Data protection information: Privacy policy > =20 > =C2=A0 > =20 > =20 > =20 > =20 > </code></pre> </blockquote> <p>-- <br></p> <div>MTG AG</div><div>Dr. Falko Strenzke</div><div><br></div><div>Phone: +4= 9 6151 8000 24</div><div>E-Mail: <a href=3D"mailto:[email protected]" t= arget=3D"_blank">[email protected]</a></div><div>Web: <a href=3D"http:/= /mtg.de" target=3D"_blank">mtg.de</a></div><div><br></div><div>MTG AG - Dol= ivostr. 11 - 64293 Darmstadt, Germany</div><div>Commercial register: HRB 89= 01</div><div>Register Court: Amtsgericht Darmstadt</div><div>Management Boa= rd: J=C3=BCrgen Ruf (CEO), Tamer Kemer=C3=B6z</div><div>Chairman of the Sup= ervisory Board: Dr. Thomas Milde</div><div><br></div><div>This email may co= ntain confidential and/or privileged information. If you are not the correc= t recipient or have received this email in error,</div><div>please inform t= he sender immediately and delete this email.Unauthorised copying or distrib= ution of this email is not permitted.</div><div><br></div><div>Data protect= ion information: Privacy policy</div><div><br></div> </blockquote></div> --0000000000002b80160656063925-- --===============0478771040097885020== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kb3BlbnBncCBt YWlsaW5nIGxpc3QgLS0gb3BlbnBncEBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVt YWlsIHRvIG9wZW5wZ3AtbGVhdmVAaWV0Zi5vcmcK --===============0478771040097885020==--