(bug?) Revoked keys and past signatures

[Peter Lebbing]

On 10/02/15 12:52, Kristian Fiskerstrand wrote:
> No, the signature is still valid:
> 
>> $ gpg2 --verify test.gpg gpg: Signature made Tue 10 Feb 2015
>> 11:53:47 CET using RSA key ID
> B2F1C0D8
>> gpg: Good signature from "Testkey 3" [unknown]
> ^^^^^^^^^^^^^^^^^^^^^^
> 

In my opinion, the signature might be /good/, but it is not /valid/. A
/good/ signature is just as good as any signature from a key you
downloaded off the internet. Here's the status-fd output:

$ gpg2 --status-fd 1 --verify test.gpg 2>/dev/null
[GNUPG:] SIG_ID mIjaz0UJC1cgEmJHXntwKHhdiuI 2015-02-10 1423565627
[GNUPG:] REVKEYSIG 08154E55B2F1C0D8 Testkey 3
[GNUPG:] VALIDSIG EFF1596F1A68F7088699579D08154E55B2F1C0D8 2015-02-10
1423565627 0 4 0 1 8 00 EFF1596F1A68F7088699579D08154E55B2F1C0D8
[GNUPG:] KEYREVOKED
[GNUPG:] TRUST_UNDEFINED
$

Note that unfortunately 'good' and 'valid' are slightly mixed up,
perhaps that's where the confusion comes from.

>     VALIDSIG    <fingerprint in hex> <sig_creation_date> <sig-timestamp>
>                 <expire-timestamp>  <sig-version> <reserved> <pubkey-algo>
>                 <hash-algo> <sig-class> [ <primary-key-fpr> ]
> 
>         The signature with the keyid is good. This is the same as
>         GOODSIG but has the fingerprint as the argument. Both status
>         lines are emitted for a good signature.  [...]

What you'd like to see, though, is TRUST_FULLY or better:

>     TRUST_UNDEFINED <error token>
>     TRUST_NEVER     <error token>
>     TRUST_MARGINAL  [0  [<validation_model>]]
>     TRUST_FULLY     [0  [<validation_model>]]
>     TRUST_ULTIMATE  [0  [<validation_model>]]
>         For good signatures one of these status lines are emitted to
>         indicate the validity of the key used to create the signature.

Note how it says /validity of the key/. It's not ownertrust it is
talking about![1]

>> gpg: WARNING: This key has been revoked by its owner! gpg:
>> This could mean that the signature is forged. gpg: reason for
>> revocation: Key is superseded gpg: revocation comment: Test
>> revocation gpg: WARNING: This key is not certified with a trusted
>> signature! 

This is exactly what a "superseded" or "retired" revocation is /not/. It
has not been stolen; the signature could not have been forged. The key
/is/ certified with a trusted signature as I've indicated in my previous
post. It's just that the key has since been revoked. The RFC clearly
says this doesn't invalidate past signatures, but this message is the
message you get for an invalid data signature.

>> gpg:          There is no indication that the signature
>> belongs to the owner.

No indication that the signature belongs to the owner... the exact same
message you get for any invalid key you just got from somewhere.

> ... However you have an unknown situation wrt the validity of the key
> having issued the signature

Why? The key was revoked because it was superseded or has been retired,
not because it was stolen or compromised.

If you're convinced you're not mistaken, could you please take the time
to show me where this data signature from a revoked key is any different
than a signature from any random invalid key?

Peter.

PS: I've tagged the subject line so it stands out more, since it seems
like a bug to me.

[1] For certifications the terminology "trust" makes sense, for data
signatures not so much, in my opinion.

-- 
I use the GNU Privacy Guard (GnuPG) in combination with Enigmail.
You can send me encrypted mail if you want some privacy.
My key is available at <http://digitalbrains.com/2012/openpgp-key-peter>