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

Hi Roberto,

Am 18.06.25 um 08:09 schrieb Roberto Hueso Gomez:
> Hi everyone! Cryptography newbie here, so this proposal might not make 
> sense at this stage, but I think it's worth discussing :)
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.
>
> I also created a GitHub issue: 
> https://github.com/openpgp-pqc/draft-openpgp-pqc/issues/220
>
> The use case is: Signing messages and software using ML-DSA-87 to 
> comply with CNSA 2.0 [1] (see "Table: Commercial National Security 
> Algorithm Suite 2.0") using keys stored in an HSM.
>
> In its current state, this draft forces us to use a composite 
> signature ML-DSA-87+Ed448.
>
> 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. 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.

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

>
> In this particular use case, continuing to use RSA signing because of 
> software/HSM compatibility reasons is a "must", so that means that 
> triple signing would be needed (i.e. ML-DSA-87+Ed448 and RSA-4096). 
> Also for compliance reasons with CNSA 1.0 [2].
That you additionally want to or need to sign with RSA is irrelevant to 
this discussion.
>
> Another concern is that, according to section 3.3 [3], "Newer 
> implementations with PQ(/T) support MAY ignore the traditional 
> signature(s) during validation." but there is no ML-DSA-only signature 
> scheme defined.
>
> Would it make sense to have an ML-DSA-87 only (non-composite) 
> signature in this draft where you also advice to use it together with 
> a classical signature algorithm but don't specify which one? (i.e. 2 
> independent OpenPGP signatures)

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.

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.

Best regards,
Falko

>
> Beyond this particular use case, I believe it adds some flexibility to 
> OpenPGP and makes it more future-proof.
>
> Thank you!
> Roberto.
>
> [1] 
> https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF
> [2] 
> https://media.defense.gov/2021/Oct/15/2002874275/-1/-1/0/CNSA_WORKSHEET_20211015.PDF
> [3] 
> https://www.ietf.org/archive/id/draft-ietf-openpgp-pqc-11.html#name-multiple-signatures
>
> _______________________________________________
> openpgp mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
-- 

*MTG AG*
Dr. Falko Strenzke

Phone: +49 6151 8000 24
E-Mail: [email protected]
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>

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