Certs by a revoked key

David Shaw dshaw@jabberwocky.com
Tue Feb 25 01:37:02 2003


On Mon, Feb 24, 2003 at 06:18:10PM -0600, Richard Laager wrote:

> > 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).
> 
> Jason Harris and I had a conversation a while ago regarding the
> proper handling of revoked keys in keyanalyze, pathfinder, etc.
> (IIRC, keyanalyze currently ignores all revoked keys, and pathfinder
> currently accepts all revoked keys.) This was when I came up with
> the stance that I have now. It's interesting that this is in the RFC
> the same way I imagined.

The RFC (2440) doesn't say this.  2440bis does (or it seems to), but
2440bis hasn't been finalized into an RFC yet and so everything in it
that isn't also in 2440 is subject to change (of course, some of the
2440bis stuff has been trickling into implementations for a while,
official standard or no).  It would be interesting to track down the
person who championed that particular language change and see exactly
what their intent was.

> > 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.
> 
> Define "globally useful". I see the use in this in my own keyring's
> trust calculations, so it would have some use right away. If this was
> to be put off until other implementations do it first, then GnuPG
> will be lagging.

Globally useful meaning if I make this statement ("I don't use this
key anymore, but it isn't compromised, so keep the trust"), it will be
more widely understood than in GnuPG alone.  A use on your own keyring
is only locally useful ;)

For example, it took a long time to get support for signing subkeys
into PGP.  Until that happened, signing subkeys were not globally
useful.

> Also, I'm looking at this from the point of view that some day I'm
> going to need to replace my 1024 DSA key with something bigger. It'd
> be nice to avoid losing all of the trust if I revoke my key with a
> superceded reason, which IMHO would be the correct procedure.

You wouldn't really lose it - if and when programs started handling
soft revocations like you hope, the trust in that key will
automatically return.

> As for the keyservers, they're broken in too many ways to count.
> That's a separate issue for a separate mailing list.

I agree about the keyserver brokenness, but it isn't really a seperate
issue.  GnuPG has to play in a larger playing field than GnuPG - if a
change like this is to be made, it has to be made with some thought as
to what this will do to other implementations and common uses.  Since
the other implementations treat soft revocations as hard revocations,
that's "failing safe", so I don't see a problem.  Perhaps someone else
does.

Perhaps Werner would comment.

David