ietf-openpgp
[Top] [All Lists]

Re: Revocation key difficulty

2002-02-26 16:57:44

On Tue, Feb 26, 2002 at 05:22:35PM -0600, 
john(_dot_)dlugosz(_at_)kodak(_dot_)com wrote:

Hmm, so how would it be used?  Alice had signed Charlie's key, and now
Alice's key is compromised, so Bob decides to remove Alice's signature from
Charlie's key.  Why?  Well, perhaps Alice is a manager and Charlie is an
employee, and Bob is the tech doing all the work.  Bob is cleaning all the
underling's keys and doesn't want to ask Alice to get involved, or maybe
she is out of reach.

So, why is it necessary to remove Alice's signature from Charlie's key?
Anyone who verifies Charlie's key will see that Alice's has been revoked
and will know to ignore it.  If you're going to distribute this
second-party revokation of signatures, why not just send out a generic
"Alice's key is bad" revokation, and that implies that it ought to be
removed from certificates too?

Exactly.  It seems to make more sense to Bob for issue a general key
revocation (sigclass 0x20) for Alice's key, rather than issue a
certification revocation (sigclass 0x30) for Alice's signature on
Charlie's key.

The problem I'm having is that the RFC says that Bob can issue a
certification revocation (0x30. NOT 0x20).  I'm not saying this is
smart, a good idea, or best practice, but the RFC explicitly says it
is possible.

If Bob does this, there is no way to differentiate between Bob's
certification revocation (0x30) of Bob's certification (0x10) of
Charlie's key and Bob's certification revocation (0x30) of Alice's
certification (0x10) of Charlie's key.

I'm including sigclasses here to help make what I'm saying clear.  The
words "certificate" and "certification" are just too similar and I
think I swapped them once or twice in my original mail.  Sorry folks.

David

-- 
David Shaw          |  Technical Lead
<dshaw(_at_)akamai(_dot_)com>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies