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

[Aron Wussler <[e-mail]>]

Hi Simo,

Thank you for having a look :)

Since version 03, we moved the NIST and Brainpool curves to a different specification [1] to make this draft less controversial and slimmer.
I understand your concern with HW modules, and given that additional codepoints 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 does not require hybrids.

Cheers,
Aron

[1] https://github.com/openpgp-pqc/draft-ehlen-openpgp-nist-bp-comp/tree/main

--
Aron Wussler
Sent with ProtonMail, OpenPGP key 0x7E6761563EFE3930



On Tuesday, 22 October 2024 at 22:49, Simo Sorce <[e-mail]> 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 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.
> 

> 

> 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 -- [e-mail]
> To unsubscribe send an email to [e-mail]