For a workflow with a central OpenPGP CA it is important that the CA can revoke its certifications. Kleopatra currently offers no GUI for that. Mostly because it is difficult to do as it would need card-edit and an editinteractor.
Since we nowadays use --quick- commands for that and add a proper GPGME op for such things please add --quick-revsig to GnuPG Stable.
| rG GnuPG | |||
| rG8a941428086b gpg: Fix iteration over signatures | |||
| rGb004701adca8 gpg: Fix iteration over signatures | |||
| rG7ec56b033647 gpg: New command --quick-revoke-sig | |||
| rG243f9176e799 gpg: New command --quick-revoke-sig | |||
| Status | Assigned | Task | ||
|---|---|---|---|---|
| Resolved | • werner | T5093 GnuPG: Add quick-revsig | ||
| Testing | • aheinecke | T5094 Kleopatra: Add "revsig" support | ||
| Resolved | • werner | T4584 --quick-sign-key offers no way to override a current certification |
I am already working on it. The gpg command will be
gpg --quick-revoke-sig USER-ID USER-ID-OF-SIGNING-KEY
in general the use of fingerprints for the USER-IDs is suggested. There will be an option third parameter to limit the revocation only to a certain user-id. But I have not yet implemented that. As it is now all non-selfsigs by the given signing key are revoked - no error if they are already revoked.
Minor remark: I would change this (in the documentation) to
gpg --quick-revoke-sig fpr fpr-of-signing-key [names]
as for --quick-sign-key, --quick-add-key, and --quick-set-expire, even if USER IDs can be used instead of fingerprints. We shouldn't advertise the usage of USER IDs, if we prefer the users to use the fingerprints. I suggest to also change user-id to fpr in the documentation of --quick-add-uid and --quick-revoke-uid. Using USER IDs for identifying keys is ambiguous and errorprone (e.g. if non-ASCII characters get involved, which, incidentally, is the reason why I started to work on KMail).
I was already considering this. I bet some people will view it as a bug if it is possible to add something other than a fingerprint. I'll change it in the man page.
The backend part is ready. Someone(tm) now needs to add it to gpgme. Extending the sign key API might be the best solution.
I've noticed an inconsistency between the command arguments in the man page and in the usage/error message.
doc/gpg.texi:
@item --quick-revoke-sig @var{fpr} @var{signing-fpr} [@var{names}]g10/gpg.c:
wrong_args ("--quick-revoke-sig USER-ID SIG-USER-ID [userids]");For --quick-[l]sign-key the usage hint is --quick-[l]sign-key fingerprint [userids].
On purpose. We actually allow user ids and gpg should somehow reflect this. As requested by you I changed it in the man page to what is suggested.
I found a bug. To reproduce generate a new key, then sign it with another key and then try to quick-revoke the signatures. This fails with "Not signed by you."
The following patch fixes this:
diff --git a/g10/keyedit.c b/g10/keyedit.c index 9f4aad24a..596662dda 100644 --- a/g10/keyedit.c +++ b/g10/keyedit.c @@ -2880,7 +2880,7 @@ keyedit_quick_revsig (ctrl_t ctrl, const char *username, const char *sigtorev, sigcount = 0; for (n=node; n && n->pkt->pkttype == PKT_SIGNATURE; node=n, n=n->next) { - sig = node->pkt->pkt.signature; + sig = n->pkt->pkt.signature; if (!keyid_cmp (primarykid, sig->keyid)) continue; /* Ignore self-signatures. */
The problem is/was that node points to the first node for the first two iterations.
By the way, --quick-sign-key after --quick-revoke-sig refuses to recertify the key. -> T4584
I recall that I had the same bug during development. Must have slipped in again - Good catch.
Yes, --quick-sign-key refuses this and I am already thinking on how to fix that. In --edit-key mode you must use --expert to allow re-certification. The way --sign-key is implemented is pretty different from my new code and thus I need to think on whether to rework the code or add some backward-compatibility hack. The new sorting approach is IMO better than the old nested state machines or however you will describe it.