Certs by a revoked key

[Richard Laager]

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

> -----Original Message-----
> From: gnupg-users-admin@gnupg.org 
> [mailto:gnupg-users-admin@gnupg.org] On Behalf Of David Shaw
> Sent: Monday, February 24, 2003 3:11 PM
> To: Richard Laager
> Cc: gnupg-users@gnupg.org
> Subject: Re: Certs by a revoked key
> 
> 
> 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?

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. So, I would consider Alice's
signature on Baker's key valid and her signature on Charlie's key
invalid.

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).

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". As for embedded devices without RTCs: I
don't have an easy answer. It's very difficult to implement OpenPGP
properly without a clock. Filling in bogus timestamps is going to
cause problems. Again, you should see that coming when you're using
known-bogus information.

Richard Laager

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

iQA/AwUBPlqm8m31OrleHxvOEQI0dgCfXC2TPaPIvbQ+MkQn2JIjr0H9fJ0AniZ8
m+9noKSB60jeXQcHYXfWFxzu
=+Owo
-----END PGP SIGNATURE-----