Re: Key Identifier

[pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)]

>I was just looking at Part 1 and noticed that the definition of how you 
>compute the key identifier has changed.
>
>You now exclude the tag, length and number of unused bits in the 
>subjectPublicKey, where in the past you only used to exclude the tag and the 
>length.
>
>Was there a particular reason to do it this way? Is that how most people are 
>computing the KeyIdentifier. As you (might) know, we are using the original 
>definition of key identifier in OCSP and this divergence might confuse people.
 
There are so many ways to compute this thing that you can't rely on any sort 
of implied key identifier, but have to use whatever form is stored in the 
cert.  If there's none stored, you're SOL, because everyone is free to compute 
it differently.  The current PKIX text is just an acknowledgement that there 
are many variations out there, which is a sensible way to go - other profiles 
which specifically require their particular way of doing it are going to run 
into problems when everyone else decides it's more useful to comply with 
another, incompatible profile.  The style guide says:
 
  Various profiles have at various times required the use of the SHA-1 hash of 
  the public key (whatever that constitutes), the SHA-1 hash of the 
  subjectPublicKeyInfo data (for some reason this has to be done *without* the 
  tag and length at the start), the SHA-1 hash of the subjectPublicKey (again 
  without the tag, length, and unused bits portion of the BIT STRING, which 
  leaves just the raw public key data but omits the algorithm identifier and 
  parameters so that two keys for different algorithms with different 
  parameters which happen to share the same public key field end up with the 
  same hash), a 60-bit hash of the subjectPublicKeyInfo (presumably with the 
  tag and length), a 64-bit hash of the subjectPublicKey (again with tag and 
  length) with the first four bits set to 0100 to indicate the use of SHA-1, 
  and some sort of unique value such as a monotonically increasing sequence. 
  Several newer profiles have pretty much given up on this and simply specify 
  "a unique value".
 
One other problem alongside the one of omitting the algorithm identifier and 
parameters is that since there's no agreement on how to generate the value, it 
creates a fine subliminal channel for leaking the private key: Just make the 
key identifier the encrypted input to the DSA kosherizer and a third party can 
recover your signing key.  This is another reason why you shouldn't let your 
CA generate your keys for you.
 
Peter.