To borrow a phrase:
Rehash alert! Rehash alert!
Which brings us back to the early proposal to identify public keys by
their message digest. The syntax:
<digest algorithm identifier>, <digest of DER-encoded public key>
should work just fine. (It works for all types of key, and the size is
constant.)
As you point out Burt, an earlier version of the current draft
specification had this in it. However, when we got to implementing we
made an observation that caused us to rethink this position.
Basically, including yet another algorithm identifier provides yet
another opportunity for two users to fail to interoperate. Although
it's probably true that we'll just recommend exactly one (e.g., MD5),
there's always the possibility that it will need to be changed.
So we got to thinking about what the key selector was really for and
what features it needed to have. I think we all agree its purpose is to
distinguish among the multiple keys available to a user. Certainly,
there are several ways by which an implementation might accomplish this.
In fact, that's exactly the point. There are many ways with which this
might be accomplished. And then we realized its actual value is
unimportant. The only thing that is important is that the value be
unique among the keys it is supposed to distinguish; a user cares about
the actual value but an implementation shouldn't care what the actual
value is.
That's when we realized that the simplest thing to do was to specify the
requirements for the value (for implementors) and let implementations
choose the value according to the requirements/needs of its users. The
best way to do this was to have the specification state the actual value
of the key selector is arbitrary but the value must have the stated
semantics.
Jim