Support for OpenPGP revocations

[ppisar]

DNF5 delegates handling signatures to librpm. There is a request for supporting key revocations in DNF5 (rpm-software-management/dnf5#1964). So I'd like to see RPM to support processing OpenPGP revocation packets.

Typically an owner of a compromised key issues a revocation certificate and appends it to a keyring associated with a YUM repository which used the compromised key for signing its packages. DNF5 is expected to redownload the keyring periodically, discover the revocation, and prevent the revoked key from any further use.

First I though we could simply remove a key from RPM database if we meet a matching revocation OpenPGP packet.

But that would be prone to reimporting the compromised key. E.g. from another YUM repository maintained by an attacker.

I conclude RPM should store revocation certificates in its database so that we can reject reimporting the revoked key. Keeping signing keys and revocations together could simplify implementation because Sequoia is deemed to support the revocations https://docs.rs/sequoia-openpgp/latest/sequoia_openpgp/struct.Cert.html and system of revocations in OpenPGP is not trivial (you can revoke a key, a subkey, or an identity).

Any opinions?

[nwalfield]

rpm-sequoia rejects signatures from revoked certificates, and revoked subkeys.

RPM PgpDigParams doesn't have a way to store bare revocation certificates (i.e., a single signature packet), which some implementations create. Per RFC 9580:

When a primary version 4 Public Key is revoked, the Revocation Signature is sometimes distributed by itself, without the primary key packet it applies to. This is referred to as a "revocation certificate". 

FWIW, Sequoia emits a primary key packet and the revocation signature, so this shouldn't be a problem (although I haven't tested it).

_pgpPubkeyMerge doesn't handle bare revocation certificates. We should fix that.