(bug?) Revoked keys and past signatures
Daniel Kahn Gillmor
dkg at fifthhorseman.net
Tue Feb 10 19:01:17 CET 2015
On Tue 2015-02-10 08:37:38 -0500, Hugo Osvaldo Barrera wrote:
> Also, I see no reason why I should not be able to assign a trust to a revoked
> key - I might trust it even if the author revoked it as superseded:
> $ gpg --edit 1BFBED44
> [... info on revoked key ...]
> gpg> lsign
> Key is revoked. Unable to sign.
fwiw, you said "assign trust" above, but then in your example, tried to
do "lsign", which is an entirely different operation from assigning trust.
> I believe the reason matters. I can even sit down with the owner of the key and
> verify his ID and fingerprint and sign it, meaning "this key belongs to this
> person, but was superseeded a week ago". If actually influences the validity of
> anything he signed up to a week ago.
your certifications (whether local or exportable) themselves have a
timestamp in them. It would be silly to certify a key and its user ID
after it was revoked by the owner; you'd be claiming "i believe that
right now this is the correct key", which is not the case.
I understand the semantics of what you're trying to do, but i'm not sure
that OpenPGP has syntax to represent it. The closest OpenPGP comes
would be to forge a certification yourself from *before* the revocation.
gpg --faked-system-time 20100105T153023 --lsign 1BFBED44
This isn't exactly the same semantics (it says "on January 5 2010 i
thought that this key was correct") but it's close.
More information about the Gnupg-users