[openpgp] Re: PQC: ML-DSA only (non-composite) signatu re

On Wed, 2025-06-18 at 09:05 +0200, Falko Strenzke wrote:
> > 
>  You are right, this request comes in very late. The working group has discussed the code point allocation extensively some time ago. The draft has just been submitted to the IESG for publication. Based on this fact alone, I hardly see any possibility to account for your request by a change.


To be fair I asked for the same months ago, but was denied.


> >  A significant portion of HSMs are not able to sign using Ed448. 
> 
> You should consider to hold the Ed448 in software while using an HSM for ML-DSA.


The reason to use an HSM is to keep keys secure and have all the
cryptography executed in a single place, it is organizationally as well
a code challenge to mix and mash, it is not as easy as you may think.


>  Incomplete hardware support, in one direction or the other (considering that PQC-capable HSMs are currently not available at all), will be a challenge for the PQC deployment in any case.


FYI, PQC capable HSM do exist and are available today (although current
models often lack hw acceleration they can execute in firmware and keep
keys secure).



> [Furthermore, as an aside, which requirement rules out using ML-DSA-65+Ed25519 in your use case?]


CNSA 2.0 requires ML-DSA-87 for all security levels.


> 
> Even ignoring the fact that the request is too late for such a substantial change, I object on the following grounds. The reason that you give is CNSA 2.0 compliance. First of all, note that the draft has already been changed to remove a blocker for CNSA 2.0 compliance, namely hash-binding that required the use of SHA-3. This was a minor and uncontroversial change without any (measurable) security implications, so it was OK for everyone to account for this specific CNSA requirement. What you request now is an extension of the code points to satisfy the specific requirements of CNSA as a particular national standard. In this context, note that the choice of code points in the draft does not at all contain combinations with Brainpool curves, thus ignoring the requirements of German (and also to some degree, I believe, generally European) national standards. Actually NIST and Brainpool curves were contained in the initial proposal and were removed after extensive discussions in the WG.


I am not sure this argument is relevant to the discussion, Roberto is
asking from a position of need that the standard does not meet today.
The need does not go away just because we do not like it, so bringing
up personal preferences is not really relevant either.


> This means that while the current set of code points allows the CNSA use case (by holding on key in software, as pointed out above), it doesn't at all satisfy the requirements of other important national standards. So before adding the code points you request, I would vote for adding back code points for composite combinations with Brainpool curves. Certainly I don't actually propose this, I just want to you demonstrate to you that in my view, your request would have to queue into a virtual priority queue behind these additions, for the reason of a balanced and fair algorithm choice.


If we had pure ML-DSA-87 we would be able to satisfy all standards, and
HW configurations, by simply applying two signatures side by side.

Clearly it is too late to change this standard, but perhaps we can
create an RFC to add mode codepoints?

> 

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

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