At its heart X.500 is a database engine that
supports very high speed searches using a hierarchical naming scheme.
It does not intrinisically have anything to do with email. The fact
that it was developed in the email(X.400) world does not mean that it
has to be used there. I have seen many non-email uses of X.500 ranging
from various directories to inventory to bill of materials and I am
talking about production systems not theoretical systems.
I'm sure that if you are holding an X.500 database, everything looks
like a nail. But I talked to someone who actually tried to use it for
certs, not less than two weeks ago at the Usenix Electronic Commerce
conference. Let me quote from their paper, "Developing and Deploying a
Corporate-Wide Digital Signature Capability", by Diane E. Coe
<dec(_at_)mitre(_dot_)org> and Judith A. Furlong
<jfurlong(_at_)mitre(_dot_)org>:
"The question remaining is how will the certificates and the CRLs be
made available to individuals and applications that need to access
them? Initially, it was envisioned that all certificates and CRLs
would be stored in the corporate X.500 directory server. X.500
provides an esaily accessible storage location for employee
information. There are, however, drawbacks to using an X.500
directory in a corporate environment.
"At MITRE, digital signatures applied to corporate information may
need be verified relatively soon after they have been applied or they
may need to be verified days, months, or even years later. In the
X.500 directory, certificates are stored in a "last in first out"
order within a user's X.500 entry and are not individually
addressable. If a user has multiple certificates (e.g. a current
certificate and some number of expired and/or revoked certificates), a
query against that user's entry in the X.500 directory will return all
of the user's certificates. The application would then need to parse
through each of the certificates to find the certificate that was
valid at the time the signature was applied. To do this, the
application must first extract the serial number from the retrieved
certificate. It then performs another query against the X.500
directory. This second query is against the certification authority's
(CA's) entry in the directory and retrieves the certificate revocation
list (CRL). If the CA's entry contains multiple revocation lists, the
application must parse through the retrived CRLs and find the first
list that was produced after the signature in question was applied.
The application then searches through the CRL to determine if it
contains the serial number of the retrieved user's certificate. If it
does, the date of revocation is checked and if the revocation date is
prior to the signature date, the signature is considered invalid. If
the revocation date is later than the signature date or if the
certificate is not on the CRL, the certificate is valid. This is
quite a bit of processing to be performed every time a signature needs
to be verified.
"To reduce the amount of processing that has to be performed to verify
a signature, a decision was made to store certificates in MITRE's data
warehouse, which is managed by a relational database management system
(DBMS). . . . This simplifies the signature verification process
significantly in that now a single query can be used to determine
whether or not a valid certificate exists. Certificates and CRLs will
continue to be stored in the X.500 directory but only the user's
current certificate and the current CRL will be stored. It is
envisioned that the X.500 directory will be used in the future for
sending and verifying secure messages and for communicating securely
with external entities."
I translate that last sentence as, "We hope it will be useful someday".
John Gilmore gnu(_at_)toad(_dot_)com --
gnu(_at_)eff(_dot_)org
Don't introduce that Tsutomu to your girlfriend.