Re: including the entire fingerprint of the issuer in an OpenPGP certification

[Ian G <[e-mail]>]

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