I shouldn't have been quite so negative regarding the possibility of providing
code for facilitating access to the directory, for I realize that it is a
problem. For me personally it is simply a resource issue -- if I could tell a
convincing story as to why all of this would eventually benefit (profit!) GTE,
I could get the necessary additional resources, although in this downsizing era
even that is somewhat problematic. But so far this looks like _pro bono_.
Are you able to send simple strings to a TCP port, and TCP-connect, send
and recv?
If so, I can help GTE operate an RFC 1202 gateway server to DAP. We can
even extend it to have the two exact functions you desire; we could
supply the certificate as specified by 1421 <cert>.
If the i/f offered the client something like
"cert -en williams(_at_)atlas(_dot_)arc(_dot_)nasa(_dot_)gov"
"cert -pem <asymmid>"
would this be simple enough?
Peter's gateway seems to be very similar in concept to some other
implementations I have seen. I certainly appreciate and am encouraged by his
offer, and would be happy to support such a function if there is agreement that
that is the way to go.
I understand Rhys' point that he wants a simple, easy to use, TCP/IP based
protocol with a minimal, preferably ASCII-based user interface, perhaps along
the lines of the human-readable (verbose) SMTP interface. Although there may be
good justification for a web-browser interface as well, this interface would be
clean and simple.
But before we jump on this suggestion (or LDAP, or several other
possibilities), let's think for just a second what functionality is really
required.
The example that Peter suggested, "cert -en
williams(_at_)atlas(_dot_)arc(_dot_)nasa(_dot_)gov"
is implicitly doing a directory Read operation, where the precise DN is known
and a single result is returned.
The more usual form of directory searches is a Browse operation, where multiple
DNs and entries may be offered for inspection, fuzzy word searches and wild
cards can be used, etc., but the human user would presumably be involved in
making the final selection.
IF the directory is only to be used to look up the certificate, and the
asumption is made that the e-mail package already knows the precise rfc822 name
(probably without the "Mr Rhys Weatherly" prefix), AND if there is only one
certificate associated with that particular DN, then a simple Read operation is
sufficient and straight-forward.
Is this all of the functionality that people think would be necessary, useful,
or desirable? Or would they like to have the ability to look up the e-mail name
as well, based on some other search index such as surname?
If only the direct Read operation is required, this could be provided rather
easily. Even if the user chooses to have an alternative, "conventional" DN
(c=US, o=U.S. Government, ou=NASA, ou=Ames Research Center, {surname=Williams +
uniqueID=123456} ), and even if the payload for that entry (including the
certificate and presumably the rrc822 name) resides on another DSA, an alias DN
or knowledge link could be created that would point to the primary entry.
(For scalability, it might be a good idea to parse the rfc822 name and separate
the final root, so that COM, ORG, MIL, EDU, and US are all located under the
country=US arc, unless the ISOC wants to include the entire world under some
global root. But the DUA interface could manage those details.)
Since the Internet Society is the official name registration authority for for
rfc822 names, it doesn't have to share that name space with any other
organization. So unlike the case of residential persons and personas, where
competing directory service providers may end up fighting over how to subdivide
the various states and cities, all of the DSA everywhere in the world could
know that if you want to access the portion of the DIT that deals with rfc822
names, you go to the Internet directory to find a pointer to the DSA where the
"real" payload is contained.
Ultimately, the DUAs will probably have to be extended to follow these kinds of
naming and knowledge links -- another reason for using a simple client/server
implementation. But with this approach the e-mail package clients can be kept
very simple, while the DUA server portion can become increasinly sophisticated
as to parallel search algorithms, accounting, access control, etc.
Speaking of access control and perhaps accounting (a dirty word, implying that
someday there might be a charge for this service), would it be a good idea to
bite that bullet now, and incorporate a signed request for the certificate?
When the directory products implement strong authentication that would provide
the necessary access control mechanisms, and if a PEM implementation can't
easily implement such a function then no one can!
Bob
--------------------------------
Robert R. Jueneman
GTE Laboratories
40 Sylvan Road
Waltham, MA 02254
Internet: Jueneman(_at_)gte(_dot_)com
FAX: 1-617-466-2603
Voice: 1-617-466-2820