The major problem I see with using HTML is the need for the email client to
retrieve the public key. They are designed to do this over LDAP. Not all
email clients are integrated with a HTML reader. The LDAP query is not
significant overhead and checks for public key data very transparently.
While SMTP and LDAP have different name spaces, it is the responsibility of
the directory manager to provide a mechanism to unify the name space of the
SMTP alias in the certificate with the SMTP alias available in the
directory. Once this is done (rather simple actually) everything works, no
matter how the DN is formatted.
I strongly disagree that LDAP can not be used as an internet infrastructure
by leveraging its use in the enterprise, and the market for various
metadirectory products seems to back me up some what.
Walt
-----Original Message-----
From: owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org
[mailto:owner-ietf-smime(_at_)mail(_dot_)imc(_dot_)org]On Behalf Of Philip
Hallam-Baker
Sent: Thursday, May 11, 2000 11:13 AM
To: ietf-smime
Subject: Border directories
Re the W2K discussion:
There is a problem with S/MIME's interaction with LDAP in general that
is certainly not unique to W2K. LDAP operates off a completely different
namespace to that of SMTP / RFC822. Furthermore there is no single
authoritative registrar for the X.500 namespace as there is for DNS (yes
I know that there are groups who claim that role but as far as I know
their authority is not generally observed).
The application of LDAP as an enterprise infrastructure is not
compatible with its use as an internet infrastructure. An enterprise
directory has much more information than anyone is going to make
available outside the company for the likes of headhunters and
competitors.
The use of border directories is one possible solution. The DNS SRV
record provides a convenient means of locating a border directory.
If however the border directory is only goiung to provide a certificate
lookup service why use LDAP when one can use HTTP with vastly less
overhead and pain? If one is not going to support indexing and search
facilities for the certificate repository why make them available at
all?
I would quite like to see an SRV information service of the following
form defined:
Service Name _SMIME-HTTP
Protocol function: For an RFC822 address of the form abc(_at_)xyz(_dot_)com
one or
more digital certificates are returned that provide a binding between
the name abc(_at_)xyz(_dot_)com and one or more public keys.
Protocol:
1) Obtain the SRV record _SMIME-HTTP.xyz.com
This contains the IP address a.b.c.d and the port p
2) Perform a retrieval query on http://a.b.c.d:p/ <name> ? <params>
The result of the query is the necessary S/MIME certificate (s)
where <name> =
"mailto:abc(_at_)xyz(_dot_)com" or Base64 ( SHA1 (
"mailto:abc(_at_)xyz(_dot_)com"))
(which TBD)
where <params> =
"something to do with specifying an acceptable certificate root"
"something to do with whether intermediate certs are required"
"something to do with the acceptable certificate format -
default X.509v3 but support DNSSEC, PGP, SPKI, NYI etc"
"something that we thought up in the bar late one night at the
IETF"
My personal prefferance would be fgor the SHA1 blinded query since it
compresses the querry and emphasizes the fact that searching for names
ain't going to be a supported feature but it does not really make the
job of searching any harder in reality.
Phill