Imagine a B2B service where two parties need to set up a two-way trust relationship: Alice will only accept requests from Bob, and Bob wants to know his requests are only going to Alice.
When setting up this relationship, Alice and Bob need to exchange their public keys. But when it comes to verification, is it enough to verify that the certificate thumbprint matches? Or, should Alice and Bob exchange the full public key?
A public key is quite long, and a thumbprint is short, so the thumbprint is more convenient. But since it is shorter, does that mean it has a higher chance of collision? How much safety is lost by only using the thumbprint to identify the caller rather than the full public key?
This page, for example, suggests that the thumbprint is fine for verifying. Can anyone confirm?
And if the thumbprint is enough, why do services like Github expect you to upload your full public key instead of just a thumbprint when establishing trust?
A hash of the public key is enough, provided it's long enough(I'd recommend 160 bits), and the hash function is resistant against second pre-images.
I guess github wants full public keys because their SSH library expects that. There are also some situations where it's useful to have the full key available. For example you can offline encrypt a message to a certain public key, but not to a hash.
The decision hash vs. public key isn't a decision based on security, but on which one is more convenient for a particular use.
External links referenced by this document: