Subject: Re: Revocation key difficulty

From: [email-masked]
Date: Tue, 26 Feb 2002 17:22:35 -0600

From: John Dlugosz

=====
A while back, someone suggested a "revocation target" signature
subpacket for revocation signatures that would contain the hash of the
signature that was being revoked.  That would fix this problem, but
I'm open to any solution - does it even make sense to allow a
revocation key to issue certificate revocations?  I always thought of
the revocation key as the "revoker of last resort" - more for
emergency key revocations in case of compromise or secret key loss
than for fine-grained control of previously issued signatures.
=====

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?

---

From: David Shaw <[email-masked]>
Date: Tue, 26 Feb 2002 18:57:38 -0500

> 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
<[email-masked]>  |  Enterprise Content Delivery
617-250-3028        |  Akamai Technologies

---

From: "vedaal" <[email-masked]>
Date: Wed, 27 Feb 2002 11:42:19 -0500

----- Original Message -----
From: "David Shaw" <[email-masked]>
To: <[email-masked]>
Sent: Tuesday, February 26, 2002 6:57 PM
Subject: Re: Revocation key difficulty

> > Charlie's key.  Why?
...
> certification revocation (sigclass 0x30) for Alice's signature on
...

A possible reason why it may be beneficial to to have a revoker selectively
revoke only the signature,
may be if one is forced to give up an RSA encryption key.
{Hopefully, this should never have to be, and the session key should be
enough for the authorities,
but if it 'were' to happen ...,}

Then, to avoid anyone else signing with Alice's key  {if it would be
surrendered},
Alice may want two separate RSA keys, her original one for encrypting, and
another one for signing.

Alice then publicly declares that she is no longer signing with her original
RSA key.

Sometime later, someone else's key that Alice once signed, is now
'questionable', and Alice wants her signature removed.
Now her designated revoker can accomplish this.

vedaal