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
revoker.
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
--
David Shaw | Technical Lead
<dshaw(_at_)akamai(_dot_)com> | Enterprise Content Delivery
617-250-3028 | Akamai Technologies