Certs by a revoked key

[Richard Laager]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Friday, February 21, 2003 6:22 AM, David Shaw wrote:
> On Thu, Feb 20, 2003 at 09:01:14PM +0100, Jan Niehusmann wrote:
...
> > "If a key has been revoked because of a compromise, all
> > signatures created by that key are suspect. However, if it was
> > merely superceded or retired, old signatures are still valid. If
> > the revoked signature is the self-signature for certifying a user
> > id, a revocation denotes that that user name is no longer in use.
> >  Such a revocation SHOULD include an 0x20 subpacket."
> > 
> > This seems to be a clarification of RFC2440, not a real change in
> > the protocol. So shouldn't gpg handle revoked keys that way?
> 
> No, because unless you are talking about a very special use where
> the sender and receiver have rigidly controlled clocks and nobody
> else can participate, there is no way to tell whether the "old
> signatures"
> predate the revocation or not.

What does the timestamp have to do with this? By my interpretation,
the RFC is saying that if a key is revoked with a reason of 0x02 (Key
material has been compromised), 0x00* (No reason specified), or this
subpacket is missing* altogether, then all of the key's signatures
are suspect and must be ignored. However, if any other reason
(currently 0x01 (Key is superceded) or 0x03 (Key is retired and no
longer used)) is given, then the signatures should be used in trust
calculations.

No comparison to the timestamp of the revocation dare be used. Many
people make revocation certificates when they generate their keys.
Besides, the timestamp is wholly irrelevant -- this is a matter of
trusting all the sigs or none of them.

There's no reason that someone's trust should be altered because they
retire an old key.

* I added 0x00 and the missing subpacket because if either of these
conditions are true, one cannot tell if they key has been compromised
or not. For safety, one has to assume the worst. This is not
explicitly stated in that section of the RFC, though.

Richard Laager

-----BEGIN PGP SIGNATURE-----
Version: PGP 7.0.4

iQA/AwUBPlkQ0W31OrleHxvOEQKmewCg561NMtdXunb1JPlBqeUODiKKR18AnR+R
OOU76K9ydiagkZb7Iy3gzINT
=YQcK
-----END PGP SIGNATURE-----