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

Hi Roberto--

On Wed 2025-06-18 08:09:23 +0200, Roberto Hueso Gomez wrote:
> 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)

As Falko mentioned, it's pretty late in the game to do this for this
draft, but (as with other PQ(/T) approaches we've discussed on-list),
the working group is entirely capable of considering this kind of
distinct public key algorithm in the future.

Nothing in this draft prevents anyone from offering two independent
OpenPGP signatures over a given message.  Indeed, it's expected that
this sort of double-signing will happen for many messages as new public
key algorithms or packet versions are introduced.

The fact that a single message might be signed by multiple keys isn't a
use case specific to PQ(/T) at all (it is also related to novel digest
algorithms, unknown signing certificates, and so on), and the general
OpenPGP ecosystem has gotten better at handling multiply-signed messages
since the wider adoption of the semantics of the Stateless OpenPGP
interface.  That said, communicating semantics to the verifier that
multiple signatures must be present to meet the desired security
threshhold is something OpenPGP can't really do right now.

So, the status of the current draft's belt-and-suspenders approach to
ML-DSA (mandating coupling it with comparable EdDSA within a single
OpenPGP signature) is a conservative cryptographic choice for the
ecosystem that everyone active in the working group was willing to work
toward.  As cryptanalysis of ML-DSA improves, the WG might well be
willing to consider adding a less conservative choice to the OpenPGP
ecosystem as well.

> Beyond this particular use case, I believe it adds some flexibility to 
> OpenPGP and makes it more future-proof.

OpenPGP's flexibility and future-proofing rests at least in part in the
ability to declare new algorithms associated with currently unused
codepoints.  It also rests on the implementers' ability to distribute
updates and to offer substantive interoperability.

If you want to propose a straightforward pure-ML-DSA codepoint as an
OpenPGP pubkey algorithm, i recommend starting with an internet draft
using one of the experimental codepoints :)

        --dkg

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