>From: Mr Rhys Weatherley <rhys(_at_)fit(_dot_)qut(_dot_)edu(_dot_)au>
>Subject: Re: IPRA Functions
>Date: Wed, 8 Feb 1995 10:27:19 +1000 (EST)
>8. GTE will write source code for accessing the directory to get
> certificates and make the source freely available to PEM implementors
> as a reference implementation. Alternatively, GTE will provide pointers
> to _freely_ available documentation on how PEM implementators can write
> their own access code from scratch.
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?
The X.500 specifications are freely available on nc-17.ma02.bull.com
Peter.
The Directory service is provided to applications through the
Directory Access Protocol (DAP), which binds a Directory User Agent
(DUA) to a Directory System Agent (DSA).
| Directory Service
| provided via DAP
|
+-----------+ | +-----------+
| | | | |
| DUA | <----------+----------> | DSA |
| | | | |
+-----------+ | +-----------+
|
Directory User |
The DAP is an OSI application layer protocol which uses the rich OSI
upper-layer infrastructure. Unfortunately, the coding investment to
implement the DAP is significant. As such, it is difficult to host
applications using the Directory on smaller workstations and personal
computers.
This memo details a local mechanism which has been successfully used
to separate the functionality of the DAP from the complexity of
implementing the DAP. That is, a split-DUA model is used: the DAP is
implemented on an entity (the "Directory Assistant"), which resides
on a capable workstation or mainframe and exports a simpler
interface, the "Directory Assistance" (DA) protocol, to other end-
systems where the user-interface resides, termed the DA-client.
Since this mechanism provides assistance to applications wishing to
access the Directory, it is termed the "Directory Assistance" (DA)
service:
| Directory Service
split-DUA provided via DAP
+-----------+ +-----------+
| | |
Directory | <----------+----------> | DSA
| Assistant | | |
| | +-----------+
+-----------+
/|\ |
| |
| DA-service |
| provide via |
| DA-protocol |
| |
------+------ |
| |
| |
| |
| |
| |
\|/ |
+-----------+ |
| | |
| DA-client | |
| | |
+-----------+ |
|
Directory User |
A DA-server listens on TCP port 411 for incoming connections. Upon
establishing a control connection, the DA-server returns a response
indicating whether the service has been started. If successful, the
response contains an IP-address and a TCP port, expressed in NVT-
ASCII, and separated by one or more instances of the space character.
This information corresponds to the TCP-endpoint that the DAP-
listener will use for the data connection.
Note that the DA-server and DAP-listener need not reside at the same
IP-address. In the future, DA-servers may employ a internal protocol
for load-balancing purposes.