verification: require more than one signature?

There are occasionally use cases where a signature verifier wants to ensure that more than one party has made a valid signature over a message.

The current sop specification only directly supports the use case where a single signature is sufficient to validate a message, even when multiple verifiers are supplied.

There are workarounds even in the status quo, for example:

• count the number of distinct lines in the VERIFICATIONS output, rather than only depending on the return code, or
• separate the verifiers into distinct CERTS objects, and run the verification against each verifier independently, counting up the number of successful verifications.

That said, maybe we want to incorporate a simpler semantic into sop verify (and sop inline-verify). If we were to add an option like --minimum-signatures=N (where N currently defaults to 1), then we would probably need to answer some tricky questions about how we count to N, such as:

• what if there is a single signature made by a signing subkey, but that signing subkey appears multiple times in the list of verifier CERTS?
• what if there are multiple signatures from different signing subkeys, but all those signing subkeys are connected to the same primary key?
• what if there are multiple signatures, made from different cryptographic key material, associated with different OpenPGP certificates, but those OpenPGP certificates share a common set of User IDs? (this might be the case, for example, when a signer is in the process of upgrading certificates but hasn't revoked the old one yet)
• what if all the signatures come from different OpenPGP certificates in a single CERTS object, but there were multiple CERTS objects specified as acceptable verifiers?

I'm open to considering adding this semantic to sop, but only if we can come to reasonable, implementable, plausibly universal answers to the above questions. If the proposed semantics solve the problem for only some fraction of the "needs-more-than-one-signature" use cases, and we ask the folks in those other use cases to fall back to some of the workarounds mentioned above, then i'd need some extra convincing that it would be worth the complexity.

I'd love to hear feedback from at least two different groups about this proposal:

• implementers: does any particular approach here seem more or less plausible to you?
• signature producers and verifiers: do you have a use case where you want the verifier to demand more than one signature, and to reject a message where there are fewer than some limit? If so, can you describe your preferred semantics, and how you'd like the verifier to express that need?