This looks like a potential approach if you consider certificate recovery
only. However, there are several other reasons why Border Directories are
required in a corporate infrastructure.
E.g., Sharing directory information with business partners - you many want
them to have access to email addresses, but not home telephone numbers.
E.g., Providing different access to employees depending on whether they are
currently inside or outside of your firewall.
E.g., Allowing different access modes, for example preventing LDAP modify
operations entering your network from untrusted sites.
And just to add our name to the list - NEXOR has an LDAP proxy product as
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
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.
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 (
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.