[Top] [All Lists]

Re: Revocation key difficulty

2002-02-27 20:40:27

On Wed, Feb 27, 2002 at 02:28:35PM -0500, Michael Young wrote:

In my previous message, I mentioned the possibility of changing the
designated revoker language to resolve this issue, but I didn't mean
to recommend that.  In fact, I might argue that the ability to revoke
individual certifications is the only meaningful use of a designated

I can see both sides of this issue.  On the one hand, additional
flexibility in OpenPGP to handle more varied uses is probably good.
Having a designated revoker that can revoke key certifications (0x30)
has also been in the standard for a long time, though as far as I
know, nobody has ever implemented it (I assume if someone had, they'd
have had the same problem and raised the same question I did).

On the other hand, I'm concerned that giving the designated revoker
such fine-grained power to influence previous actions of the key owner
could be dangerous.  I rather like the idea that the absolute worst
thing a rogue designated revoker could do is revoke your key.

Even though the standard allows for more, as far as I know, the only
implementation that does designated revokers is PGP, and it does only
full key revocations (0x20).  GnuPG will start doing designated
revokers RSN, and I wrote the code to only do full key revocations as
well, though I'm open to changing that.

If I want to limit my designated revoker to flushing my whole
key, I can do that *much* more easily -- I can generate my
own revocation, and encrypt it to my designated revoker.
(If you're so afraid that your designee will lose the thing,
put it in a notation packet in another signature, and
ship it off to a keyserver for archiving. ;-)  Doing it that
way doesn't depend on everyone having my revoker's key for
verification, or even knowing who the revoker might be.
This seems so vastly superior to me that I can't imagine
using the designated revoker facility for this purpose.
(Am I missing something?)

Think about this from the perspective of a large company, and it makes
more sense.  You'd want a company key to be designated revoker for
everyone, but storing and keeping track of thousands of revocations is
a pain.  Having a revocation key that can be used when needed is far
simpler.  Also, it sounds a bit easier to automate putting the
revocation key on each new company key as it is created than it is to
automate generating a revocation and sending it to the right person
for storage and later use.


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