Certs by a revoked key

[David Shaw]

On Mon, Feb 24, 2003 at 05:12:52PM -0600, Richard Laager wrote:

> > > If I'm revoking my key with a 0x03 signature, it's because I no
> > > longer use my key. But, if Alice has signed my key, and I've
> > > signed Charlie's key, there's no reason Alice can't continue to
> > > view Charlie's key as valid through the signature chain, as she
> > > had before.
> > 
> > How would you handle this scenario: Alice signs Baker's key at
> > timestamp 1, and Charlie's key at timestamp 3.  Now, we get a 0x01
> > or 0x03 revocation for Alice's key with timestamp 2.
> > 
> > What does this mean to Alice's signature on Charlie's key?  On top
> > of that we've already established that we can't trust any
> > timestamps, so what does it mean to Alice's signature on Baker's
> > key?
> 
> Well, according to the letter of the RFC, "...old signatures are
> still valid." If one was to count new signatures as valid, then the
> revocation would be pretty much useless.

Not completely true - the 0x01/0x03 revocation means "don't use this
key except for trust calculations".  The key still wouldn't be used
(for encryption), so the revocation is not useless.

> So, I would consider Alice's
> signature on Baker's key valid and her signature on Charlie's key
> invalid.

I agree.

> As a threat model, an attacker could still cause problems by forging
> the timestamp on signatures made after the revocation. But, then
> again, if an attacker has your private key, all bets are off. The
> only way to prevent this sort of attack would be to use a
> "compromised" revocation reason (or not give a reason).

Werner and I had a mail conversation about this a few months ago that
you and I have more or less reconstructed at this point ;) (I was
arguing for the same thing you are arguing for).

Forgetting the RFC for a moment, note that if this was implemented,
GnuPG would be the only program that handles "soft revoked" keys
properly.  There is a huge software base (including PGP) that treats
them as hard revoked.  This is not a reason not to do it, of course,
or we'd never progress, but it does mean that even if it is
implemented, it won't be globally useful for a long time until more
programs support it.  Similarly, the keyservers don't handle this, so
soft revoked keys appear hard revoked.

> I don't believe that timestamps are untrustworthy though. Computers
> have clocks which should be set properly. If you're not going to set
> your clock properly, it shouldn't surprise you that certain things
> like this may appear "wrong".

To clarify: I'm more concerned about a malicious user setting their
clock incorrectly on purpose, rather than clocks being untrustworthy
in general.  A malicious user - or even Alice - can continue to issue
signatures from a soft revoked key by manipulating the timestamps.  It
could be argued that this isn't a problem.  If someone other than
Alice has the secret key, then the key should be hard revoked, and if
Alice is the one doing it, well, it's Alice's key anyway.  Using that
logic, it could even be argued (though I disagree and I believe you do
too) that the signature on Charlie's key from the example should be
valid.

David