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
signature.asc
Description: PGP signature
_______________________________________________ Gnupg-users mailing list Gnupg-users@gnupg.org https://lists.gnupg.org/mailman/listinfo/gnupg-users
