Certs by a revoked key

[Richard Laager]

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

On Monday, February 24, 2003 6:06 PM, David Shaw wrote:

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

Good point.

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

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.

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

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.

As for the keyservers, they're broken in too many ways to count.
That's a separate issue for a separate mailing list. I've been filing
bug reports and feature requests against PKS in SourceForge, so we at
least have somewhere to track these issues. I can't speak for other
key server implementations.

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

ACK 100% If Alice is manipulating timestamps, there's no way for us
to tell if that's the case. It could be that she had made the
signatures in the past and they never found their way to use until
the current time.

Richard Laager

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

iQA/AwUBPlq2QW31OrleHxvOEQL5WACeP8Thf8BGOvQv3FGUiq3hcEGDrfEAnR7T
INIxrKn0DI+ZKaf5uN3uOqpk
=KOPF
-----END PGP SIGNATURE-----