[Top] [All Lists]

RE: Border directories

2000-05-11 11:19:33
The lovely thing about directories is that they can be chained rather easily
(Netscape as an exception here but that is one of the reasons Sun bought
Innosoft) so if you have access to one directory, that one might be chained
to one hundred and you would never know it.  I obviously need to give you
access to my directory to make this work.  Directories have not been over
sold, they've been under implemented.  That is changing fast.


-----Original Message-----
From: Philip Hallam-Baker [mailto:pbaker(_at_)verisign(_dot_)com]
Sent: Thursday, May 11, 2000 1:49 PM
To: 'Walter Williams'; Philip Hallam-Baker; ietf-smime
Subject: RE: Border directories

HTTP, not HTML. An HTTP retrieval protocol can be written in 100
lines by any competent coder in less than a day.

And no, the email clients ability to do this over LDAP is not
currently enough. My email client will not locate your cert because
it is chained to only 8 directories.

There is a need for email clients to be able to use SRV records to
locate directories.

My problem is not with the LDAP technology though but the market
understanding thereof. Directories have been vastly oversold as
a panacea for every IT problem.


-----Original Message-----
From: Walter Williams [mailto:walter(_dot_)williams(_at_)genuity(_dot_)com]
Sent: Thursday, May 11, 2000 1:19 PM
To: Philip Hallam-Baker; ietf-smime
Subject: RE: Border directories

The major problem I see with using HTML is the need for the email client
retrieve the public key.  They are designed to do this over LDAP.  Not
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
the directory manager to provide a mechanism to unify the name space of
SMTP alias in the certificate with the SMTP alias available in the
directory.  Once this is done (rather simple actually) everything works,
matter how the DN is formatted.

I strongly disagree that LDAP can not be used as an internet
by leveraging its use in the enterprise, and the market for various
metadirectory products seems to back me up some what.


-----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 
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
namespace to that of SMTP / RFC822. Furthermore there is no single
authoritative registrar for the X.500 namespace as there is for DNS
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

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
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

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 
more digital certificates are returned that provide a binding between
the name abc(_at_)xyz(_dot_)com and one or more public keys.


1) Obtain the SRV record
    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 ( 
(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

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.


<Prev in Thread] Current Thread [Next in Thread>