Date: Wed, 23 Oct 2024 05:47:09 +0000
To: Simo Sorce <simo@redhat.com>
From: Aron Wussler <aron@wussler.it>
Message-ID: 
 <ZJRdviAbKNAn5vagDb0tt4IyBGe1YAZ6-UFM_qYnWlgQGhkxcuGzjIhBgVg5vyQ4430rxz2KYbvsm6TFvAGCYLuo_zX9U9FI6kJBlSxyUAc=@wussler.it>
In-Reply-To: <e7d89e79829bb2af14d45c18195a77d31b93ffe0.camel@redhat.com>
References: 
 <172952468697.1996193.18317768871302868182@dt-datatracker-78dc5ccf94-w8wgc>
 <lgzJzv6GX9ZQ_K3bRqIi9ASxbjwaZFahcghzBaHLReMHIfVpudSlnWe9wCrKniruARt3AzOpEkT8WBWjO4N1ksP9LLcq4pBu0VhrzOyqbJE=@wussler.it>
 <a40dad1bdb5f67586cff31469ee08d58accef8d5.camel@redhat.com>
 <e7d89e79829bb2af14d45c18195a77d31b93ffe0.camel@redhat.com>
Feedback-ID: 10883271:user:proton
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature";
 micalg=pgp-sha512;
 boundary="------9ba9fbbfd8ee31ef32beaccdb93418243c66af76cbd90453e8fa40a261047f4d";
 charset=utf-8
Message-ID-Hash: PVSMYZWETRYIIVTLFWJ55Y3WX7Q7NKUG
CC: "openpgp@ietf.org" <openpgp@ietf.org>
Precedence: list
Subject: =?utf-8?q?=5Bopenpgp=5D_Re=3A_Fw=3A_New_Version_Notification_for_draft-ietf-?=
	=?utf-8?q?openpgp-pqc-05=2Etxt?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/openpgp/BsBpB0B9dWPyYR0VTyNmaT_RiJs>

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------9ba9fbbfd8ee31ef32beaccdb93418243c66af76cbd90453e8fa40a261047f4d
Content-Type: multipart/mixed;boundary=---------------------52b1e0247a3440891236ede86498c539

-----------------------52b1e0247a3440891236ede86498c539
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;charset=utf-8

Hi Simo,

Thank you for having a look :)

Since version 03, we moved the NIST and Brainpool curves to a different sp=
ecification [1] to make this draft less controversial and slimmer.
I understand your concern with HW modules, and given that additional codep=
oints can be standardized with expert review (no need for an RFC), I feel =
like the split draft approach caters to everyone, without slowing the main=
 draft down.

As a side note, the KEM proposed in this draft should be FIPS certifiable:=
 FIPS 203 is now out, and the key derivation / combination can be seen as =
an SP 800-108 derivation of the resulting secret. The CNSA 2.0 guideline d=
oes not require hybrids.

Cheers,
Aron

[1] https://github.com/openpgp-pqc/draft-ehlen-openpgp-nist-bp-comp/tree/m=
ain

--
Aron Wussler
Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930



On Tuesday, 22 October 2024 at 22:49, Simo Sorce <simo@redhat.com> wrote:

> On Tue, 2024-10-22 at 16:42 -0400, Simo Sorce wrote:
> =


> > Hi Aaron,
> > =


> > great work on the update!
> > =


> > That said I have to ask is there is apce for adding NIST ECC curves
> > here.
> > =


> > While Ed25519/Ed448 have been recently approved for use in FIPS module=
s
> > via revision 5 of FIPS-186 there is yet no approval for the use of
> > X25519/X448 as SP 800-56A has not been extended to cover them.
> > =


> > It would be useful if at least one KEM option would be defined using
> > NIST curves for the classic algorithm part.
> > =


> > Ideally bot KEM and Signatures can use the classic NIST approved
> > curves, as adding an Edwards curve implementation to existing modules
> > may not be trivial and time would be better spent properly implementin=
g
> > ML-DSA and ML-KEM while reusing a proven and hardened P256/P384/P521
> > implementation for the classic part.
> > =


> > I understand the desire to avoid too many combinations, but a standard
> > should also look at the practicalities of deployment IMHO.
> > =


> > HTH,
> > Simo.
> =


> =


> That 'apce' above is a typo for "space" ... sigh.
> =


> And I forgot to add that if classic NIST curves where available, then
> existing and certified HW tokens that implement those curves could be
> used in conjunction with a non certified software implementation of ML-
> KEM and ML-DSA resulting still in a FIPS compliant tool as for KEM
> combiner the PQ part is just seen as additional data and does not
> "break" FIPS compliance, while for Signatures the certified signature
> function is sufficient to claim a compliant verification is done.
> =


> This means existing tokens could be used while we wait for new ones
> that can provide certified ML-KEM and ML-DSA implementations.
> =


> Simo.
> =


> --
> Simo Sorce
> Distinguished Engineer
> RHEL Crypto Team
> Red Hat, Inc
> =


> _______________________________________________
> openpgp mailing list -- openpgp@ietf.org
> To unsubscribe send an email to openpgp-leave@ietf.org
-----------------------52b1e0247a3440891236ede86498c539--

--------9ba9fbbfd8ee31ef32beaccdb93418243c66af76cbd90453e8fa40a261047f4d
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: ProtonMail

wrsEARYKAG0FgmcYjdIJkH5nYVY+/jkwRRQAAAAAABwAIHNhbHRAbm90YXRp
b25zLm9wZW5wZ3Bqcy5vcmchLGd57K5KJ4FVELMO5/qM34MFFV5ejYUxSpRH
yqkM9RYhBIuVslFfa7tqthSdVX5nYVY+/jkwAAAQzAD/UKAZTo2GgG8Fbt1H
invqoTYP7ys/w74x5NcuUDTXLugBAP1i54NuEXNVv/XfhxBF+dCNcm8Cy/FJ
Oj2Oi/GTrvYM
=tJu0
-----END PGP SIGNATURE-----


--------9ba9fbbfd8ee31ef32beaccdb93418243c66af76cbd90453e8fa40a261047f4d--