Re: Re: Best practices for signature verifcation

[Demi Marie Obenour <demiobenour () gmail com>]

On 12/31/25 08:07, Simon Josefsson wrote:
> "What to use instead?" is indeed the bigger question, and it get lost in
> all the GnuPG bashing.  To my mind, the alternatives are in a seriously
> worse state than GnuPG is in.  So in some sense, the practical
> consequence of moving away from GnuPG is to weaken people's security,
> which is something to consider when giving advice here.  I think we
> should all be worried about this state of affairs, and try to improve
> things, instead of telling people to stop using strong proven solutions.
>
> A small survey:
>
> 1) X509 with CMS/PKCS#7 - I'm happy that few appear to seriously
> consider this, since that ecosystem have almost all of PGP's flaws but
> add tons of more complexity to run attacks through.

Unless the CMSAlgorithmProtection attribute is added (RFC8933), it's
also vulnerable to algorithm substitution attacks.  No such attacks
are currently known, but the fact that is even possible indicates
a misdesign.

I do think that better CMS/PKCS#7 implementations would be worth
pursuing.  This is because it is hard-coded into a huge number
of applications that will be extremely difficult to change.
These include:

- Windows and UEFI Authenticode.
- macOS and iOS code signing.
- Legally binding CMS Advanced Electronic Signatures (CAdES).

> 2) Special-purpose tools like Minisign, signify, ed25519-cli, and
> saltpack.  Typically lacks a stable specification and/or decentralized
> process to pave the way to add PQ options.  Often lacks protocol
> specifications for MIME integration, file format conventions, and
> sometimes lack multiple interoperable implementations.

Signify at least provides a way to change the algorithm in the future,
by replacing the "Ed" bytes.  This will break all of the existing
consumers, though.

> 3) Age.  Modern design with multiple implementations and decent
> documentation.  Lacks sign+verify.  Lacks MIME interaction.
>
> 4) SSH signatures.  Reasonable minimal design, multiple implementations,
> integration into Git, IETF standardization work in progress [1] and some
> PQ drafts [2] [3].  Lacks MIME integration.  No encryption support.  I
> wish 'age' supported SSH signatures to make this format more popular.

I like this one.  It also has fields that could be used for structured
metadata in the future.

> 5) XMLDigSig and JSON Web Signatures.  (I hope I manage to provoke both
> communities by placing these two in the same category.)  Reasonably well
> specified with multiple implementations, although suffering from
> non-minimal design and canonicalization concerns.  The toolchain to work
> with these blobs is often web-oriented and primitive implementations are
> lacking, making it less suitable for low-level software supply-chain
> integrity protection.  For JSON some PQ alternatives exist.  Both
> ecosystems are negatively tainted by the X.509 WebPKI complexity.

XML-DSIG is even worse than OpenPGP or CMS.  See XML Signature Wrapping
and the endless stream of vulnerabilities in SAML implementations.
Peter Gutmann refuses to support it in cryptlib because it requires
a full XML processor.

https://portswigger.net/web-security/jwt lists design problems with
JSON Web Signatures.

> 6) Sigstore and Sigsum.  (I hope I provoke both camps here too :)) These
> are modern designs that realize that signatures without transparency is
> not effective against practical attacks.  Reasonable well specified,
> although lacking in multiple implementations and PQ options.  Sigstore
> suffer from complexity and its focus on container security.  Sigsum
> suffer from lack of non-Go implementations and MIME integration.

Sigstore also focuses on short-lived certificates, with issuance gated
by OAuth.  It relies on a transparency log to detect misissuance.
Sigsum seems to lack this weakness, but post-quantum threshold
signatures might be needed for reasonable post-quantum signed logs.

> 7) Non-GnuPG PGP implementations.  This offers a simple migration path,
> and some have already taken it.  The complexity of PGP is still present,
> and most of the attacks are consequences of the PGP design rather than
> GnuPG problems.  GnuPG is shipping PQ options already and the others are
> catching up, but the PGP schism is likely to cause continued eco-system
> self-harm.  While one could have hoped for something here, I'm not sure
> if this offers enough beyond a non-GPL license.

Sequoia provides memory safety and better testing, though the LGPL
license is a horrible fit for Rust due to the unstable Rust ABI.

> Did I forget some option?
>
> Personally, I'm staying with GnuPG using Ed25519 keys on physical
> hardware dongles and I'm adding Sigsum, using a different Ed25519 key on
> the same physical device, see a GNU InetUtils release --
> https://lists.gnu.org/archive/html/bug-inetutils/2025-12/msg00017.html
> -- for inspiration.  I will help with SSH Signature standardization and
> PQ options, since I believe SSH Signatures is the approach that is
> nearest a IETF-level standardization maturity.  I hope/encourage that
> Sigsum will add PQ options, a C+Python implementation, and resolve MIME
> integration -- and that Sigstore will continue to offer a challenging
> popular competitor.  I believe that Ed25519+SLH-DSA is the best
> near-term PQ variant for long-term software protection, alas no
> practical tools offers this today.

Would it be possible to standardize some form of metadata for SSH signatures?

CMS and OpenPGP support time-stamping countersignatures is critical.
This is critical for some applications, notably Authenticode and CAdES.
Should this be supported?

> /Simon
>
> [1] https://datatracker.ietf.org/doc/html/draft-josefsson-sshsig-format-03
> [2] https://datatracker.ietf.org/doc/html/draft-josefsson-ssh-sphincs-01
> [3] https://datatracker.ietf.org/doc/html/draft-josefsson-ssh-ed25519mldsa65-01
>
> kf503bla () duck com writes:
>
> > then what do you suggest to use? i hear it all the time "pgp sucks" but what's the alternative huh?
> >
> > > In light of the recent GnuPG vulnerabilities, I remembered that OpenPGP
> > > is almost never the right choice. CMS/PKCS#7 isn't any better, and
> > > X.509 is also bad except that its extremely wide deployment in TLS
> > > keeps it alive.
> > >
> > > See https://www.latacora/com/blog/2019/07/16/the-pgp-problem/
> > >
> > > and https://soatok.blog/2024/11/15/what-to-use-instead-of-pgp/.
> > >
> > > --
> > > Sincerely,
> > > Demi Marie Obenour (she/her/hers)


-- 
Sincerely,
Demi Marie Obenour (she/her/hers)

Attachment: OpenPGP_0xB288B55FFF9C22C1.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature