[openpgp] Re: WG Last Call: draft-ietf-openpgp-nist-bp-com p-04 (Ends 2026-09-09)

Dear Werner, dear all,

Thank you for your support of the additional curves.

I think this is an important step toward improving interoperability 
within the OpenPGP ecosystem. More generally, I believe that convergence 
on a common base standard, in particular RFC 9580, is important. 
Fragmentation at that level would ultimately be harmful to OpenPGP 
adoption and acceptance.

Concerning the algorithm IDs:

In RFC 9980, we assigned:

30–31 ML-DSA+Ed* composites
32–34 SLH-DSA
35–36 ML-KEM+X* composites

I would therefore propose 37–44 for the additional ML-KEM / ML-DSA 
composites, as follows:

37 ML-KEM-768+ECDH-NIST-P-384
38 ML-KEM-1024+ECDH-NIST-P-521
39 ML-KEM-768+ECDH-brainpoolP384r1
40 ML-KEM-1024+ECDH-brainpoolP512r1
41 ML-DSA-65+ECDSA-NIST-P-384
42 ML-DSA-87+ECDSA-NIST-P-521
43 ML-DSA-65+ECDSA-brainpoolP384r1
44 ML-DSA-87+ECDSA-brainpoolP512r1

This also preserves the ordering of the currently assigned experimental IDs:

100 ML-KEM-768+ECDH-NIST-P-384
101 ML-KEM-1024+ECDH-NIST-P-521
102 ML-KEM-768+ECDH-brainpoolP384r1
103 ML-KEM-1024+ECDH-brainpoolP512r1
104 ML-DSA-65+ECDSA-NIST-P-384
105 ML-DSA-87+ECDSA-NIST-P-521
106 ML-DSA-65+ECDSA-brainpoolP384r1
107 ML-DSA-87+ECDSA-brainpoolP512r1

Best,
Stavros


On 8/20/26 10:49, Werner Koch wrote:
> Hi!
>
> On Wed, 19 Aug 2026 09:35, Daniel Gillmor said:
>> This Working Group Last Call ends on 2026-09-09
>>
>> Abstract:
>>     This document defines PQ/T ("post-quantum/traditional") composite
>>     schemes based on ML-KEM and ML-DSA combined with ECDH and ECDSA
>>     algorithms using the NIST and Brainpool domain parameters for the
>>     OpenPGP protocol [RFC9580], and as such extends [RFC9980].
>>
>> File can be retrieved from:
>> https://www.ietf.org/archive/id/draft-ietf-openpgp-nist-bp-comp-04.txt
> I support this document and I am eagerly waiting for getting algorithm
> ids assigned.
>
> Aside of this, I am still highly critical towwards the entire rfc9580 et
> al. documents.  However, given that some governmental entities really
> want this break in OpenPGP, the additional curves are a good move.
>
>
> Shalom-Salam,
>
>     Werner
>
>

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]