[openpgp] Re: draft-ietf-openpgp-nist-bp-comp: add Categor y-5/P-384 combinations

--===============8366857518687487101==
Content-Type: multipart/alternative; boundary="000000000000c90ee60655f299c0"

--000000000000c90ee60655f299c0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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: 2026. 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-384 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 s=
oftware
> 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]
> 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
>
>

--000000000000c90ee60655f299c0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><p class=3D"gmail-PDq2pG_selectionAnchorContainer">Hello F=
alko,<span aria-hidden=3D"true" class=3D"gmail-PDq2pG_selectionAnchor"></sp=
an></p>
<p>Thanks for the question.</p>
<p>I did not mean that any single one of the existing profiles requires bot=
h hybrid use and category-5 ML-* alone.</p>
<p>My point is interoperability across profiles: some environments allow P-=
384 but not P-521, while other requirements may call for category-5 ML-*. I=
mplementations may need one standardized hybrid option that works across as=
 many such environments as possible.</p>
<p>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 us=
able across multiple profiles and avoids private, non-standard combinations=
.</p>
<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 &lt;<a href=3D"mailto:falko=
[email protected]">[email protected]</a>&gt; ezt =C3=ADrta (id=C5=91pont=
: 2026. j=C3=BAl. 6., H, 16:35):<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"><div class=3D"msg-5324464731610947643"><div><div>Hi Gergel=
y,</div><div><br></div><div>On Sat, 2026-06-20 at 22:56 +0200, NGG wrote:</=
div><blockquote type=3D"cite" style=3D"margin:0px 0px 0px 0.8ex;border-left=
:2px solid rgb(114,159,207);padding-left:1ex"><div dir=3D"ltr">Hello OpenPG=
P WG,<br><br>I would like to suggest adding the following optional combinat=
ions to=C2=A0draft-ietf-openpgp-nist-bp-comp:<br><br>* ML-KEM-1024+ECDH-NIS=
T-P-384<br>* ML-DSA-87+ECDSA-NIST-P-384<br><br>The current draft pairs the =
category-5 ML-* parameter sets only with=C2=A0P-521, while P-384 is paired =
with category-3.<br><br>The motivation is compliance interoperability.<div>=
Some deployed profiles,=C2=A0including CNSA 1.0 and NATO FMN certificate pr=
ofiles,=C2=A0<span style=3D"background-color:transparent">admit P-384 but <=
/span><span style=3D"background-color:transparent">not P-521.</span><div><s=
pan style=3D"background-color:transparent">Separately, other policies or de=
ployment requirements=C2=A0</span><span style=3D"background-color:transpare=
nt">may call for the category-5 ML-* parameter sets.</span></div></div></di=
v></blockquote><div>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 c=
ould simply be ignored for the signature at least.</div><div><br></div><div=
>Falko</div><blockquote type=3D"cite" style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:2px solid rgb(114,159,207);padding-left:1ex"><div dir=3D"ltr"><div=
><div><div><br>These are not necessarily requirements imposed by the same p=
rofile, but<span style=3D"background-color:transparent">=C2=A0software may =
need to operate across several such environments.</span></div><div>Standard=
ized P-384/category-5 combinations would provide a useful=C2=A0intersection=
.<br><br>There is already relevant IETF precedent:<br><br>* The TLS ECDHE-M=
LKEM specification defines SecP384r1MLKEM1024.<br>* The LAMPS composite-sig=
nature specification defines id-MLDSA87-ECDSA-P384-SHA512.<br><br>These com=
binations could be added alongside the existing P-521 variants,=C2=A0withou=
t changing or replacing them.<br><br>Would the WG consider adding them?<br>=
<br>Best regards,<div>Gergely Nagy</div></div></div></div></div><pre>______=
_________________________________________</pre><pre>openpgp mailing list --=
 <a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>=
</pre><pre>To unsubscribe send an email to <a href=3D"mailto:openpgp-leave@=
ietf.org" target=3D"_blank">[email protected]</a></pre></blockquote><d=
iv><br></div><div><span><pre>-- <br></pre><div>MTG AG</div><div>Dr. Falko S=
trenzke</div><div><br></div><div>Phone: +49 6151 8000 24</div><div>E-Mail: =
<a href=3D"mailto:[email protected]" target=3D"_blank">falko.strenzke@m=
tg.de</a></div><div>Web: <a href=3D"http://mtg.de" target=3D"_blank">mtg.de=
</a></div><div><br></div><div>MTG AG - Dolivostr. 11 - 64293 Darmstadt, Ger=
many</div><div>Commercial register: HRB 8901</div><div>Register Court: Amts=
gericht Darmstadt</div><div>Management Board: J=C3=BCrgen Ruf (CEO), Tamer =
Kemer=C3=B6z</div><div>Chairman of the Supervisory Board: Dr. Thomas Milde<=
/div><div><br></div><div>This email may contain confidential and/or privile=
ged information. If you are not the correct recipient or have received this=
 email in error,</div><div>please inform the sender immediately and delete =
this email.Unauthorised copying or distribution of this email is not permit=
ted.</div><div><br></div><div>Data protection information: Privacy policy</=
div><div><br></div></span></div></div>
</div></blockquote></div>

--000000000000c90ee60655f299c0--


--===============8366857518687487101==
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: base64
Content-Disposition: inline

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kb3BlbnBncCBt
YWlsaW5nIGxpc3QgLS0gb3BlbnBncEBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVt
YWlsIHRvIG9wZW5wZ3AtbGVhdmVAaWV0Zi5vcmcK

--===============8366857518687487101==--