On Fri, Aug 24, 2001 at 04:42:36PM -0700, Jon Callas wrote:
Secondarily, one way I look at it is as a receiver. I fetch a key from a
server and it has multiple primaries. How do I resolve this? Yeah, there's
been one recommendation in the last 24 hours since I started writing this
reply that it be the first one that counts. Why? Why the first? Why not the
last? I can make a convincing argument that it should be the last one, too.
But why the last. Why not the one with the latest date? I think I can argue
that the latest date is even more correct than either the first or the
last, unless of course it's in the future. Perhaps an even better answer is
to have the implementation ask the user which one to use.
This is my point: I don't see an obvious best answer. Furthermore, 2440 is
a data specification standard, not a user interface guide or software
construction manual. It tells implementers the things they have to do to be
compliant. What this really says that if you ever see a key with multiple
primary user names, then your guess is as good as mine, and I'm not going
to wag my finger at you for whatever rationale makes sense for you.
What do you think about adding some text to help resolve multiple
self-signatures? Multiple primary user names are one thing, but
self-signatures can carry subpackets with serious implications.
For example: take a key with two self-signatures, one with a
revocation key set and one without. Which is right? Granted, it is
very hard to tell for all the reasons you gave above, but the penalty
for guessing wrong here is much worse. If I add a revocation key to
my key and the revocation key is later compromised, I would want to
ensure the compromised key could not revoke mine. Without even a
recommendation on how to resolve two self-signatures, the result could
be that my key would be revocable on some implementations, but not
others. It's a great denial of service attack against the key owner.
Similarly, let's say that a few years down the road someone manages to
break one of the symmetric ciphers. The solution is for the user to
not accept that cipher via the "preferred algorithms" packet. With
two self-signatures and no way to disambiguate them, the broken cipher
may be used, which can compromise the secrecy of the message.
I strongly favor a recommendation to use the most recent
self-signature. Picking the first or last doesn't make much sense to
me, as the signature packets could be placed in any order or
rearranged at any time. It may not be a perfect way to resolve
conflicts, but it should be able to resolve a large majority of them.
If recommending to use the most recent isn't possible, even a line or
two to mention that this is not a casual question and that there are
security implications to picking the wrong self-signature would be
good. At least it would remind people of the issue.
David
--
David Shaw | Technical Lead
<dshaw(_at_)akamai(_dot_)com> | Enterprise Content Delivery
617-250-3028 | Akamai Technologies