Following on from my previous message, here is a "what if" document. It
is not seriously being proposed as standards-track at the moment. Just
pointing out where my "referral" ideas could lead to. Feel free to pull
it to pieces. This is just a draft, and not complete yet.
The big hole in this is how to handle users without TCP/IP connections,
but e-mail gateways should be sufficient for most cases. IMHO, of course.
Cheers,
Rhys.
---------
A lightweight TCP protocol for accessing a PEM certificate repository
GOALS
* Simple protocol, similar to existing TCP protocols (ftp, nntp, smtp, etc).
* Able to give referrals to other servers if a certificate is not kept
locally.
* Able to estimate the "certainty" of a referral to help clients home in on
the right server quickly.
* For lookup operations, servers should not need any cryptographic
functionality. All certificate verification is done in the client.
However, servers may want to internally sign their databases to
preserve their contents from tampering. This is a local matter.
PROTOCOL OVERVIEW
Based on ftp, nntp, smtp in that commands are sent to the server which send
back a response consisting of numeric and textual parts. Numeric response
codes obey the following conventions:
1XX Information messages
2XX Success messages
3XX Success, but more data required
4XX Failure messages
5XX Command error messages
X0X Atomic response, no following text
X1X Textual data follows
Textual responses follow the usual nntp and smtp conventions: lines are
terminated by CRLF, and the text is terminated by a line with a single '.'
on it. Lines in the original text that being with '.' have an extra '.'
prepended.
PROTOCOL STARTUP
Protocol startup returns a 200 or 201 response, as follows:
200 hostname message
201 hostname message
where "hostname" is the fully-qualified domain name of the host, and "message"
is any text message (usually the software version and compile date).
A 200 response indicates that the server can accept certificate signing
requests and/or certificate revocation requests. A 201 response indicates
a read-only server that can only lookup certificates or referrals. A
server may be capable of operating in both modes, but use a reverse lookup
on the client's IP address to set the mode accordingly. A server that
returns a 200 response can still refuse a request if it chooses.
COMMANDS TO LOOKUP CERTIFICATES
There are a number of methods to look up a certificate, depending on the
information the client has at its disposal. Each of the commands returns
certificates or referrals in the same manner. Only the command syntax
is different.
The DN command takes an X.500 DN as an argument and returns either a
certificate or a list of referrals. Syntax:
DN
311 Send base64-encoded X.500 DN
MII.....
.
The DNPARTIAL command takes an X.500 DN as an argument, but instead of
being a whole DN, it contains only a subset of the attributes of the
DN desired. This is useful when you know, say, the country and organisation
name, but nothing else about the user's DN. Everything else is the same
as the DN command.
The EMAIL command takes an Internet e-mail address as an argument. It
is followed directly by the response codes described below. i.e. there
is no additional data as for DN and DNPARTIAL.
The NAME command takes a printable human name as an argument, possibly
including spaces. It is assumed that the character set is US-ASCII by
default. This can be overridden by using the '=?' header encoding
mecahnism of MIME part 2. It is considered an error to send ISO-8859-1
or any other 8-bit character set text without being encoded because the
initial requests may be to servers that don't use the same character set.
Everything else is the same as the EMAIL command.
Note: other commands that use regular expressions and what-not are possible,
but I haven't defined them as yet.
After the lookup command has been sent, the server will give another response
code indicating failure (401, 402, or 403), success (211), or referral
(212).
401 indicates an error in the format of the DN. 402 indicates that no such
certificate exists, and that no other server will have it. 403 indicates
that the server does not have the certificate, and there are no known
referrals (but it may exist elsewhere).
A success response code is followed by a textual response which includes
base64-encoded versions of one or more X.509 certificates. The certificates
are separated by blank lines. Normally only a single certificate will be
returned, but sometimes (especially with the NAME command), there may be
more than one certificate that matches the criteria.
In the case of DNPARTIAL, it is better to provide referrals to servers
handling the CA's of the partial matches rather than return certificates for
the partial matches. (This is a dodgy criterion, I know).
A referral response code is followed by a textual response consisting of
one or more lines of the following form:
hostname<TAB>port<TAB>certainty
The "hostname" is a fully-qualified domain name for another server conforming
to this protocol. "port" is the port number the server can be found on.
"certainty" is the certainty factor for the referral, a number between 0
and 100. The numbers can be roughly divided into:
0 Probably doesn't have it at all, but may have a better
idea. This would normally be returned by the IPRA for
each of its PCA's.
50 Has a good idea of where to refer you to. This would
normally be returned by the IPRA or a PCA which refers the
client to another PCA which can tell you the right CA.
75 Has a very good chance of knowing the certificate. This
is normally returned by a PCA which is indicating which
CA to refer to.
100 The server definitely has the certificate, or knows if the
certificate doesn't exist at all.
Note: further fields may be added in future. Therefore, if a <TAB> follows
the "certainty" rating, ignore it and the rest of the line.
A typical sequence of actions (with no prior caching) would be the following:
(a) Contact the IPRA server. It will return a list of PCA's with
certainty 0-49.
(b) Sort the referral list by descending order of certainty.
(c) Try each of the servers on the referral list in turn, collecting
responses. They will normally return referrals in the range
50-100. After each server has been visited, resort the list and
remove duplicates and servers that have already been visisted.
(d) Repeat from step (c) until there are no more servers to try,
a certificate has been found, or a definite "no such certificate
exists" response (402) is received.
[This is as far as I've gotten so far]