There is another question, related with this suggestion: imagine i want
to "hide" my public key, in order to give it only to "selected users" ?
This is a valid method to increase security in the exchange of
information between specifics users. Introducing the public key as a the key
selector removes this possibility.
I question whether hiding the public key really is a valid method for
increasing security, even though it seems it should be at first sight.
Why do you want to hide your public key?
A. Are you going to share this "private" public key with only one
other user? If so, then why bother with public key cryptography? Why
not use DES instead?
B. If you are going to share the public key with multiple users, how
private do you realistically expect the public key to remain?
C. If you are going to keep the public key private to prevent someone
(or some nasty government spy agency) from seeing the modulus and
factoring it, is this realistic? Can you really keep it private
forever if you are giving it out, albeit limitedly? In any case, this
criteria is not a stated goal of this standard.
D. If you are keeping you public key private to avoid having third
parities figure out who you are or who you're sending messages to, Bob
Jueneman has done a thought experiment which nicely shows how hiding
the public key does not necessarily accomplish this. I have included
the message below. And again, protection from such analysis is not a
stated goal of this standard. If it were a stated goal, the standard
would have explicitly described the layers of mechanisms that have to
be piled on top of hiding the public key to accomplish the goal.
Conclusion: Hiding the public key may be nothing more than feel-good
security. If this standards group is going to pursue a requirement
for security from originator/recipient analysis or hiding of the
modulus to prevent factoring, then we must agree to this explicitly,
not by reading between the lines. And we would need more than the 48
hour timeout that Jim Galvin put forth.
Let me explicitly ask Jim Galvin again: The public key itself is a
simple, sufficient and universally available way of selecting among
the keypairs that a user might have. What is the reason for adding
the complexity of arbitrary key selectors? And if it is for some
security purpose, can the complexity be justified by a cryptographic
analysis that shows that the complication actually adds security? If
so, we must put this analysis in the MIME/PEM spec or refer to
appropriate documents. Please don't just explain again how to
implement the complication. It must be justified.
- Jeff
Included message from Bob:
It certainly shouldn't be necessary, and in many cases may not be desirable,
to
send the originator's certificate along with the message, especially if the
certificate contains all of the details of your name, rank, and serial number
in the clear. John Gilmore made that point rather persuasively over three
years
ago, and turned my thinking around. Likewise, if you are communicating with
someone via some kind of a blind forwarding mechanism, you don't want the
identity of the recipient to be disclosed, either. (In this case I assume that
you would double encrypt the message to your recipient, so that only the
forwarder would know who to send the inner message to. But the forwarder could
also reencrypt the message, including your orignal certificate, so only the
forwarder would know who was communicating with him or her.) Yet I suppose
that
it is desirable that both the originator's and recipient's certificates be
identified somwhow, if only to avoid having to try multiple certificates to
see
which one works.
We have the Persona type of certificates, of course, but I guess that it could
be argued that this is an undesirable bit of extra process to use for the
purpose you described.
Let's see. Suppose that the recipient has a dozen keys that he or she uses at
various times. Is it too much effort to simply try them all? After all, any
other approach is going to require sending SOME kind of an identifier, and
sooner or later someone would be able to put two and two together. And by the
way, a dozen is probably rather extravagent. Except for some of the idiots on
the news groups that conceal their identities under multiple names to avoid
being caught by someone's kill file, it is hard to imagine a need for more
than
two or three, depending on the number of roles that someone has. (Unless they
are really paranoid, and use a key of the day concept.)
A full message digest of the key would probably be too revealing, since it
would map directly to the certificate/key itself. I wouldn't hink that you
would want to use a bare key, for the same reason -- too much correlation from
message to message. But what if we were to use just a one or two byte hash of
the key, or maybe just an index into the user's key space. In fact, if the
recipient had only one CA/issuer of certificate/keys, we could just use the
sequence number of the key itself for this purpose.
Unless the recipient uses a different key for each different mailbox address,
I
don't yet see how the key selector mechanism really solves this problem. I
suppose you could put something in the private name space to say "this is from
the friend you met last night -- use your key number 3 and my key number 17."
But did I miss something? All this seems like a lot of trouble for two
consiprators to go to -- they might as well agree on a secret triple-DES key
and be done with it, or just talk in the parking lot while they are secretly
exchanging disks.
Bottom line -- I'm not yet convinced of the need to adopt addition mechanisms,
when what we have available now can solve the same problem and be more
compatible with existing standards and implementations.