Jim Galvin writes:
1. Do you want the key selector because it hides the public key so
that people cannot factor the modulus?
Yes. In fact, it was included in the design because we were told it had
to be there.
You were told by whom? And how do I sign up to wield this kind of
power over you? As a test case, here goes: I tell you it does *not*
have to be in there... What? My statement hasn't change the standard
in a flash? :-\ (face contorted in dumbfoundment)
Jesting aside, what's going on is that things are obvious to you, or
obvious to the people who tell you what to do, or justifications are
given in conversations you have with people, but you just don't seem
to realize that this information has not been supplied to the rest of
us on pem-dev, and getting you to supply these justifications IS LIKE
PULLING TEETH! Maybe you don't know how to supply them because you
think that just because you've heard it, we have. (I dunno...)
Steve Kent has just asked you to cite the strong justifiction which
motiviated all the effort to hide the public key. Please don't be
suprised at this. It's a reasonable request because the reason the
public key disappeared *has not yet been stated to the working group.*
The scheme for hiding the public key just showed up "because we were
told it had to be there."
You also write.
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.
Again, it's not fair to call this a rehash, since this is the first
time this information has appeared on pem-dev and the first I've heard
of it. And that you do call it a rehash concerns me because you don't
seem to be aware of what you've explained (and haven't) to whom, but
I'm too glad that it has finally come out to get upset. :-)
In order to respond specifically to your message I first need to ask a
few questions of the implementors who have said they want a public
key digest (which I will do seperately).
- Jeff