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

[Falko Strenzke <[e-mail]>]

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>