[openpgp] Re: Fw: New Version Notification for draft-ietf-openpgp-pqc-05.txt

[Simo Sorce <[e-mail]>]

Thank you both for the clarification, somehow I confused myself and
forgot about the split. Excellent work!

On Wed, 2024-10-23 at 07:58 +0200, Falko Strenzke wrote:
> Hi Simo,
> 
> Am 22.10.24 um 22:49 schrieb Simo Sorce:
> > 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 modules
> > > 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 implementing
> > > 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.
> 
> Just as you argue with good reasons in favour of including the NIST 
> curves, from the perspective of those domains that fall under the 
> regulations or recommendations of the BSI, one could argue for the 
> inclusion of the Brainpool curves. The WG had decided that these 
> additional curves (NIST, Brainpool) be moved to a different draft: 
> https://datatracker.ietf.org/doc/draft-ehlen-openpgp-nist-bp-comp/. And 
> that is what will stick to –unless there is consensus to overrule this 
> WG decision again, but that is currently not at all apparent in my view.
> 
> This draft will be presented to working group again. For the moment, the 
> authors of draft-ehlen-openpgp-nist-bp-comp have decided to wait with 
> approaching the WG (again) until the constructions in the main draft 
> (draft-ietf-openpgp-pqc) are stable.
> 
> - Falko
> 
> > 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.
> > 
> -- 
> 
> *MTG AG*
> Dr. Falko Strenzke
> 
> Phone: [phone]
> E-Mail: [e-mail]
> Web: mtg.de <https://www.mtg.de>
> 
> ------------------------------------------------------------------------
> 
> MTG AG - Dolivostr. 11 - 64293 Darmstadt, Germany
> Commercial register: HRB 8901
> Register Court: Amtsgericht Darmstadt
> Management Board: Jürgen Ruf (CEO), Tamer Kemeröz
> 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 
> <https://www.mtg.de/en/privacy-policy>
> 

-- 
Simo Sorce
Distinguished Engineer
RHEL Crypto Team
Red Hat, Inc