Certs by a revoked key

David Shaw dshaw@jabberwocky.com
Mon Feb 24 22:11:01 2003


On Mon, Feb 24, 2003 at 02:43:50PM -0600, Richard Laager wrote:

> > Let's make sure we're talking about the same thing.  What exactly
> > are you suggesting here?  It sounds like you are saying that the
> > 0x01 and 0x03 revocation reasons are a "revocation lite" that means
> > "don't use this key anymore, but don't really fully revoke it in
> > terms of the web of trust either".
> 
> Indeed. I believe that's the reason for having these classifications.
> RFC 2440bis says, "There are important semantic differences between
> the reasons..."
> 
> If I'm revoking my key with a 0x01, it's because I intend to move on
> to a new key. There's no reason to lose all the trust of the old key.
> It can be passed on (in a sense) by signing my new key with my old
> key prior to revocation.
> 
> 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?

David

-- 
   David Shaw  |  dshaw@jabberwocky.com  |  WWW http://www.jabberwocky.com/
+---------------------------------------------------------------------------+
   "There are two major products that come out of Berkeley: LSD and UNIX.
      We don't believe this to be a coincidence." - Jeremy S. Anderson