However, in light of the excellent work done by Warwick and his
compatriots, and echoing John Linn's suggestion, instead of
continuing to roiund and round on this, maybe we could first ask
Jim Galvin for a reprise as to why the current mechanism was
adopted by TIS in the first place, and what problems it was
supposed to solve that weren't addressed by the PEM RFC. I think
I know in general, but I would like to hear a detailed analysis
to refresh all of our memories.
Quoting from the introduction of the PEM Security Services and MIME
specification:
In order to make use of the PEM services, a user is required to have at
least one public/private key pair. Prior to this specification, the
public key was required to be embodied in a certificate, an object that
binds a public key with a distinguished name, a name form that
identified the owner of the public key. The embodiment was issued by a
certification authority, a role that was expected to be trustworthy
insofar as it verified the identity of the owner prior to issuing the
certificate. However, the deployment of certificates and the creation
of the hierarchy of certification authorities has been problematic.
Instead, this specification bases the PEM services on a public/private
key pair. Each key pair is required to belong to a user (where user is
not limited to being a human, e.g., it could be a process or a role)
which has a name. There are 3 name forms specified by this document.
For backward compatibility (and forward compatibility if the X.500
Directory becomes a ubiquitous service) one of the name forms is a
distinguished name. In addition, email addresses and arbitrary strings
are allowed.
Since a user may have more than one key pair, a name form is
insufficient for uniquely identifying a key pair. A unique key selector
must be assigned to each key pair. The combination of a name form and a
key selector uniquely identifies a key pair and each key pair is
uniquely identified by a name form and key selector combination.
Throughout this document, this combination is called an identifier.
There are 5 identifiers specified by this document.
My point is, I would have expected this last paragraph to read:
Since a user may have more than one key pair, a name form is
insufficient for uniquely identifying a key pair. Therefore, the
public key is used to identify the keypair.
We need a way to distinguish among possible key pairs. Why shouldn't
it be the public key? I haven't heard any reason why not. Why even
introduce key selectors? I haven't heard why this complexity was
introduced. All I've heard from Jim is lots of reccomendations on how
to implement the complexity. That is no justification for it.
Just using the public key is the simplest approach. I will give my
specific reccomendations in response to Jim Galvin's call for
comments.
- Jeff