Revoked keys and past signatures

[Hugo Osvaldo Barrera]

On 2015-02-10 12:28, Peter Lebbing wrote:
> On 09/02/15 20:34, Daniel Kahn Gillmor wrote:
> > the *date* of your "key was superceded" revocation is relevant,
> > though. Any certifications that claim to have happened after the date
> > of the revocation *should* be considered invalid, whereas revocations
> > that happen before that date (but after the key creation date) should
> > retain their validity.
> 
> (By the way, I'm going to treat data signatures, not certifications,
> since I believe that was what Hugo reported)
> 
> I started to think you were right and I was mistaken, but I can
> reproduce Hugo's scenario:
> 
> $ 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" [full]
> 
> Note how verify-options show-uid-validity notes it is fully valid. It is
> signed by an ultimately trusted key.
> 
> Now I revoke it:
> 
> $ gpg2 --edit-key B2F1C0D8
> gpg (GnuPG) 2.0.26; Copyright (C) 2013 Free Software Foundation, Inc.
> This is free software: you are free to change and redistribute it.
> There is NO WARRANTY, to the extent permitted by law.
> 
> Secret key is available.
> 
> pub  1024R/B2F1C0D8  created: 2014-02-24  expires: 2015-02-17  usage: SC
>                      trust: never         validity: full
> sub  1024R/98AC4DFA  created: 2014-02-24  expired: 2014-03-03  usage: E
> [  full  ] (1). Testkey 3
> 
> gpg> revkey
> Do you really want to revoke the entire key? (y/N) y
> Please select the reason for the revocation:
>   0 = No reason specified
>   1 = Key has been compromised
>   2 = Key is superseded
>   3 = Key is no longer used
>   Q = Cancel
> Your decision? 2
> Enter an optional description; end it with an empty line:
> > Test revocation
> > 
> Reason for revocation: Key is superseded
> Test revocation
> Is this okay? (y/N) y
> 
> The following key was revoked on 2015-02-10 by RSA key B2F1C0D8 Testkey 3
> pub  1024R/B2F1C0D8  created: 2014-02-24  revoked: 2015-02-10  usage: SC
>                      trust: never         validity: revoked
> The following key was revoked on 2015-02-10 by RSA key B2F1C0D8 Testkey 3
> sub  1024R/98AC4DFA  created: 2014-02-24  revoked: 2015-02-10  usage: E
> [ revoked] (1). Testkey 3
> 
> gpg> save
> $
> 
> Now let's check that signature again:
> $ 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]
> 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!
> gpg:          There is no indication that the signature belongs to the
> owner.
> Primary key fingerprint: EFF1 596F 1A68 F708 8699  579D 0815 4E55 B2F1 C0D8
> $
> 
> The dates for signature and revocation are the same, but the times are
> reasonably far apart:
> $ gpg2 --export B2F1C0D8|gpg2 --list-packets
> :public key packet:
>         version 4, algo 1, created 1393271747, expires 0
>         pkey[0]: [1024 bits]
>         pkey[1]: [17 bits]
>         keyid: 08154E55B2F1C0D8
> :signature packet: algo 1, keyid 08154E55B2F1C0D8
>         version 4, created 1423566838, md5len 0, sigclass 0x20
>         digest algo 8, begin of digest 9c c5
>         hashed subpkt 2 len 4 (sig created 2015-02-10)
>         hashed subpkt 29 len 16 (revocation reason 0x01 (Test
> revocation))
>         subpkt 16 len 8 (issuer key ID 08154E55B2F1C0D8)
>         data: [1024 bits]
> [...]
> $ date -d "1970-01-01 +1423566838 secs UTC"
> Tue 10 Feb 12:13:58 CET 2015
> $
> 
> That's twenty minutes later. I don't see a reason for GnuPG to round to
> full days when it has resolution down to the second for the times the
> signatures (data, revocation) are made... is there?
> 
> The RFC clearly states "key superseded" doesn't invalidate old signatures:
> 
> > However, if it was merely superseded or retired, old signatures are
> > still valid.
> 
> But using GnuPG 2.0.26 on Debian jessie/testing, package 2.0.26-4, I can
> reproduce signatures becoming invalid... what's going on? Does GnuPG not
> implement the RFC here or is it a bug?
> 
> HTH,
> 
> Peter.
> 
> -- 
> 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>

I haven't read the RFC, so I don't know if something is define in this exact
scenario, but it does sound like a bug.

I imagine that recipients of all my emails for the past four years now looking
at their archives will find that my messages have no valid signature, and that
must be slightly disturbing.

I'll read the RFC if I have time and see if something specific is defined.

Thanks for testing this thuroughly.

Also, thanks Daniel for confirming that the reason *is* stored.

Cheers,

-- 
Hugo Osvaldo Barrera
A: Because we read from top to bottom, left to right.
Q: Why should I start my reply below the quoted text?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: </pipermail/attachments/20150210/8ee95628/attachment.sig>