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

--===============3251872654376498644==
Content-Type: multipart/alternative; boundary="0000000000009aedd50654b5a3e5"

--0000000000009aedd50654b5a3e5
Content-Type: text/plain; charset="UTF-8"

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.

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

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

<div dir=3D"ltr">Hello OpenPGP WG,<br><br>I would like to suggest adding th=
e following optional combinations to=C2=A0draft-ietf-openpgp-nist-bp-comp:<=
br><br>* ML-KEM-1024+ECDH-NIST-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=A0=
P-521, while P-384 is paired with category-3.<br><br>The motivation is comp=
liance interoperability.<div>Some deployed profiles,=C2=A0including CNSA 1.=
0 and NATO FMN certificate profiles,=C2=A0<span style=3D"background-color:t=
ransparent">admit P-384 but </span><span style=3D"background-color:transpar=
ent">not P-521.</span><div><span style=3D"background-color:transparent">Sep=
arately, other policies or deployment requirements=C2=A0</span><span style=
=3D"background-color:transparent">may call for the category-5 ML-* paramete=
r sets.</span><div><br>These are not necessarily requirements imposed by th=
e same profile, but<span style=3D"background-color:transparent">=C2=A0softw=
are may need to operate across several such environments.</span></div><div>=
Standardized P-384/category-5 combinations would provide a useful=C2=A0inte=
rsection.<br><br>There is already relevant IETF precedent:<br><br>* The TLS=
 ECDHE-MLKEM specification defines SecP384r1MLKEM1024.<br>* The LAMPS compo=
site-signature specification defines id-MLDSA87-ECDSA-P384-SHA512.<br><br>T=
hese combinations could be added alongside the existing P-521 variants,=C2=
=A0without changing or replacing them.<br><br>Would the WG consider adding =
them?<br><br>Best regards,<div>Gergely Nagy</div></div></div></div></div>

--0000000000009aedd50654b5a3e5--


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

X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18Kb3BlbnBncCBt
YWlsaW5nIGxpc3QgLS0gb3BlbnBncEBpZXRmLm9yZwpUbyB1bnN1YnNjcmliZSBzZW5kIGFuIGVt
YWlsIHRvIG9wZW5wZ3AtbGVhdmVAaWV0Zi5vcmcK

--===============3251872654376498644==--