sopv-gpgpv: an implementation of the verification-only subset of the Stateless OpenPGP CLI using gpgv as a backend

[Daniel Kahn Gillmor]

On Mon 2024-08-05 20:08:43 +0200, Björn Persson wrote:
> It's true that requiring verification of all the signatures is not
> always desirable. Allowing all but one to fail is not always right
> either. Deciding how many correct signatures should be required is
> nontrivial. I doubt any general verification tool can automatically do
> the right thing in every case without parameters telling it what's
> desired in the specific usecase.

Requiring N signatures to validate is indeed an interesting scenario,
but it is very far from the common scenario.

The common scenario is that there is only one signature available.  You
want to make sure that signature validates.

If a second signature appears, that second signature should not break
the validation unless you have some prearranged knowledge that more than
one signature should be present.  Your Bitcoin example is an unusual
outlier, which i can't speak to because i don't know the full history
there.  I can probably identify one other signing scenario where
everyone involved knows that you should have multiple signatures, but
these are the exceptions, not the rule.

So yes, there is an argument to be made for some (very unusual) cases
where you want at least N-of-M signatures to be validated.

But that amount of complexity, compared to the overwhelming number of
actual use cases that we see simple at-least-one signature verification
used for, is not a great tradeoff.  sopv handles the common base case
correctly, without brittleness.

> So gpgv has a limitation, and sopv-gpgv has a limitation, but sopv-
> gpgv's limitation would be worse for a distribution's security.

I don't think i agree with you, but we seem to be looking at things from
different perspective.  I think you're asking "how can we make a
stronger verification framework that can require redundant signatures?"
while I'm asking "how can we make a stronger verification framework that
lets us deploy cryptographic updates promptly, without coordinating a
flag day?"

But these things aren't mutually exclusive.  For example, you can use
the sopv return code as a baseline (we all agree that we want at least
one valid signature, and should fail if there are none), and then only
accept if you count the distinct lines you care about in the
VERIFICATIONS output if you want to require more than 1 signature.

Or, you could verify the thing multiple times, once against each
verifier you care about, and count up the number of successful
verifications.

Or, if you really want the "sop verify" and "sop inline-verify"
interface to support some sensible "at least N signatures" semantic, feel
free to open a suggestion in the sop issue tracker:

  https://gitlab.com/dkg/openpgp-stateless-cli/-/issues/new

You can get feedback there from multiple implementers, based on what you
propose.

I've toyed with trying to add that semantic in the past myself, but i
never hit on an approach that seemed more convincing than the techniques
i outlined above.  There are some subtle questions that i don't know how
to answer for such a verification requirement by default, like: how do
you want to count "distinct" signatures?  What if there are two
signatures from the same signing-capable subkey?  what if there is one
signature from a signing-capable subkey that is bound to two distinct
primary keys? What if there are two separate signatures, from different
signing-capable subkeys, but they're both attached to the same primary
key?  What if there are valid signatures from two separate primary keys,
each of which have produced a signature, but the certificates for those
primary keys share a user ID?

On the flip side, "at least one signature from this pool of signers must
be valid" is understandable, implementable, unambiguous. And it is
effective for the vast majority of use cases.  That's why sop (and the
sopv subset) uses it as a baseline.

> I don't remember ever seeing an example of that approach.

You haven't seen that approach commonly because it's impossible to
deploy new signatures while tools like gpgv produce a failure when they
encounter an unknown signature.

What I want is an ecosystem where it's possible for the *signer* to
adopt new signature mechanisms as soon as possible (presumably using the
new scheme in parallel with older signing capabilities), and for the
*signer* to decide when to stop making old/weak signatures.  That gives
the verifiers clear motivation to upgrade.  And it also allows any
verifier who is unwilling to rely on older/weaker signatures the chance
to make that switch without having to wait on every other verifier
having upgraded to be able to discover signatures from the new
algorithm.

Brittle verification tools are holding back the ecosystem, and their
brittleness doesn't even bring any concrete benefit to their users.
Let's use a more reasonable interface.

      --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 324 bytes
Desc: not available
URL: <https://lists.gnupg.org/pipermail/gnupg-users/attachments/20240806/544fa24a/attachment.sig>