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

Daniel Kahn Gillmor <[email protected]>
Newsgroups gmane.ietf.openpgp
Message-ID <[email protected]>
On Wed 2025-06-18 17:34:59 -0400, Simo Sorce wrote:
> On Wed, 2025-06-18 at 14:33 -0400, Daniel Kahn Gillmor wrote:
>> 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 :)
>
> How thrilled would you be to see experimental codepoints in shipping
> code and official signatures on released documents ?

That would go pretty clearly against the explicit goal of experimental
and private use codepoints.

The objective of using experimental codepoints while drafting is to give
people a chance to write test code to confirm shared understanding and
trial interoperability between draft/prerelease versions of code; not
to release code directly.

This is how the OpenPGP PQC draft was developed.  We only settled on
non-experimental codepoints once we had demonstrated prerelease
interoperability, to avoid injecting potentially ill-formed artifacts
into the wild.

If someone wants to advance a "pure ML-DSA-87" signing mode draft, i'd
hope they would follow a similar process.

> Because the problem here is trying to meet requirement with official
> signatures shipping by the end of the year (CNSA 2.0 also has deadlines
> for the end of 2025).

I don't see how CNSA 2.0 would be broken by making a ML-DSA-87+Ed448
signature, given the way that these composite signatures are defined,
but i'll grant i'm not an expert or authority in CNSA's requirements
either.

It seems to me that, given that both components (ML-DSA-87 and Ed448) of
the signature must be independently valid for the composite signature to
be valid, the obligation to use ML-DSA-87 should be met here.

As an analogy-driven thought experiment, consider the file length
information that ships alongside cryptographic digest information in a
Debian "Packages" file
(e.g. http://deb.debian.org/debian/dists/stable/main/binary-amd64/Packages.gz)

If the retrieved file is a different size, there's no need to check the
digest.  But the cryptographic strength of the digest is not weakened by
also checking the file size.

By the same token, an ML-DSA-87 signature isn't weakend by also checking
the Ed448 signature.

Regards,

         --dkg

_______________________________________________
openpgp mailing list -- [email protected]
To unsubscribe send an email to [email protected]
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.