I think it really is just aesthetics whether you use the left or right bits
as a key id. I also believe that the left bits are the more aesthetic ones
to use, and I say that as a confirmed little-endian.
I'll also concur that the key server can use whatever bytes it wants.
That's no biggie.
If I were to make a V5 key structure, the thing I'd change would be *not*
to include the key creation time in with the SHA-1 hash for the
fingerprint. This was unfortunate. It means that two keys that have the
same key material, but different creation times have different key ids. At
one time I thought this was a feature, and I've come to believe it's a bug.
If I were really going to roto-till the spec, I'd get rid of key ids
altogether and only use fingerprints. There have already been problems with
key id collisions, and it would be much better to just use fingerprints. We
already say that you SHOULD NOT assume they're unique, but arguably that
really should be MUST NOT.
However, I think that none of those changes can be made. There comes a
point in any protocol's life where you just live with the warts because
correcting them causes more problems. The key id selection is one of those.
If we change things, we add more cruft into a system that already has cruft
in it.
There is already a separate algorithm for V3 keys and V4 keys. This would
give us another one, and one that exists for no good reason. And as Hal has
mentioned, the proper proper fix would be to make the UI that shows a 32
bit key id show the left 32 bits rather than the right ones. Fortunately,
we've managed to bury that issue completely and not even mention them. 32
bit key ids only exist in implementations.
Jon