Jeff> You mention that all you have to do is "store one additional bit
of information in your X.500 directory". To someone who wants
to use an existing database to simply work with MIME-formatted
messages, it is not a small deal to rework the database just to
do this, if that is required to be MIME/PEM compliant.
Jim> There is no additional bit to store, per se. If you are storing issuer
name and serial number than you can store name form and key selector.
If you can lookup by issuer name and serial number than you can lookup
by name form and key selector.
If you have chosen to tightly-couple your implementation to knowledge of
the structure of the values you are looking up with, then it is possible
you may have some database work to do. That would be an unfortunate
result of the choice of database mechanism you made in the first place.
Jim, on the one hand you say that existing databases made an
unfortunate choice if they attributed meaning to the database index.
You say an implementation should treat <issuer name/serial number> the
same as the new MIME/PEM <arbitrary string/arbitrary key selector>.
There is just one blob index which you take from the Originator-ID
as-is and feed to the database to get the certificate. This is how
you justify the dubious claim that existing database implementations
can implement all the new name forms without change.
But elsewhere you say:
Bob> If I don't already have the certificate in hand from the
originator and only have the key digest, I haven't any idea
where to look until a worldwide directory of keys indexed by
such digests comes into existance.
Jim> I couldn't agree more. This is an excellent reason for not using just a
digest of a public key.
The same objections made to a key digest apply equally to the
arbitrary index blob which is the basis for your claim that all the
name forms can be implemented easily. Consider:
Jim> Jeff Thomson has been the principal advocate of just using the public
key. While I agree it is sufficient for the purposes of supporting
the PEM services, it is insufficient for supporting PEM-based
applications. Warwick Ford provided the ideal example of why this is
so: the public key is an insufficient general database index.
(For my purposes here, I am not discussing the
public-key-only-as-identifier, which was intended to reference
information within the same message. I am discussing the notion of
one database index serves all name forms.)
Warwick's objections to using a public key digest as a general
database index directly disqualify the database scheme you propose for
supporting arbitrary key identifiers:
Jeff> >2. If I understand you, an integer is the best key selector because
the public key itself is too big as a database index and a hash allows
the possibility of collisions (albeit 1 in 2^32 or 1 in 2^128). Have
I understood this correctly?
Warwick> Yes, these are important points.
Warwick's assertion is that an arbitrary string is too big to use as a
database index, which is exactly what you are recommending. The
reason the distinguished name is not considered too big is precisely
because the database has "chosen to tightly-couple your implementation
to knowledge of the structure of the values you are looking up with."
X.500 people use the structure of the distinguished name to distribute
the database. And when I helped design the Orcale database which is
used by RSA's Commercial Hierarchy (and the Certificate Issuing System
which Bob uses) we seperated out the common name or organization name
as a separate index because Oracle can process it more easily in order
to do the case insensitive searches required for distinguished names.
These are precisely the kind of databases that will choke when they
have to comply with MIME/PEM's arbitrary names and key selectors,
especially if they have to implement your suggestion of just accepting
an unformed, unknown length string as an index.
Bob> > If I wanted to store PEM/MIME certificates in an X.500
> directory, perhaps using the Bell Northern Entrust program, do
> I have to do something new?
Jeff> Yes.
Jim> No.
Yes, for the reasons stated above.
- Jeff