On 21/01/11 3:00 AM, Jon Callas wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
A side-effect of this is something that's either an obvious extension or in the
spec already.
Section 3.3 says: "Implementations SHOULD NOT assume that Key IDs are unique."
It's said that since 2440, for the following reason...
In PGP1 days, Vinnie started working there and told me that he'd generated a
key and gotten a certain error when putting it into the keyserver. I was
thrilled, because that error was a duplicate keyid error. We'd been having
debates over this ourselves. Being a software engineer, I tend to consider
assuming that a database key is unique is bad form. I recognize that
pseudo-random 64-bit numbers don't collide easily at all, but assuming
uniqueness is something that is easily coded around. That key was my proof that
engineering-wise, don't assume uniqueness.
Sadly, he had deleted the key and just generated a new one, so that key is the
Nessie of key ids. It's a crypto-cryptologist's dream, the true random
collision. And we will never know if it was genuine. Sigh.
Nonetheless, that led to that clause in 3.3, and I assert that if an
implementation breaks because of a keyid collision, the implementation has a
bug.
Fascinating anecdote! Definately one to debate over beers:
I'd not go so far as to agree that the implementation has a bug. I'd
say this is the difference between "security culture" coding and an
ordinary user-grade coding.
Which is to say, as long as the error is rare enough, and as long as the
knee-jerk reaction of the code at the top of the stack is approximately
useful, and as long as this is a standard-grade application, it's
reasonable to kick it way up there.
In this case, the exception went all the way up the stack into the
wetware, and Vinnie responded by re-generating the key! Problem solved.
This "reboot" methodology made Bill Gates a lot of money...
OTOH, if we were engaged in building a "security culture" product we
would want to solve this in lower layers.
iang