This seemed like a neat idea, so I've written up. I'm sure somebody's already
thought of this, but here goes anyway.
Mike
**********************************************************************
Use of Privacy Enhanced Mail by Gopher
Michael Roe
Computer Security Group
Cambridge University Computer Laboratory
10th November 1993
1. Introduction
The mechanisms described in this memo have two purposes:
a) To add data integrity and data origin authentication services to the gopher
protocol, making use of the certificate-based key distribution mechanism
already developed for Privacy Enhanced Mail.
b) To enable Privacy Enhanced Mail to use gopher to obtain key certificates,
in situations where an X.500 Directory Service is not available.
2. Message Types
The following PEM message types are suitable for use with gopher:
* MIC-ONLY
* MIC-CLEAR
* CRL
To use these PEM messages with gopher, new gopher document types need to be
assigned. At the minimum, a single new document type (``PEM message'') could
be used to carry all of these. However, it will aid gopher user agents if
a separate gopher document type is used for each of these three PEM message
types.
In addition, if multiple PEM content-domain types are to be used (e.g.. to
carry bitmapped images inside PEM messages), then it desirable to have a
separate gopher document type for each combination of PEM message-type and
PEM content-type. CRL messages do not have a message body, and so the PEM
content-domain is not applicable to these messages.
The following PEM message types are not suitable for use with gopher:
* CRL-RETRIEVAL-REQUEST
* ENCRYPTED
3. Client Procedures
3.1 MIC-CLEAR and MIC-ONLY
When directed by the user to retrieve documents of these types, the gopher
user agent should retrieve the document and then submit it for normal PEM
message processing as per RFC 1421. If a security error is detected, the
user agent should signal this to the user. Otherwise, the user agent should
display to the user the body of the message, the Distinguished Name of
the PEM message originator, and the Distinguished Name of the Policy
Certifying Authority in the message's certification path (if any).
If multiple PEM content-domains are used, then the PEM content-domain
field can be used to determine how to render the message body. (e.g.. whether
it is ASCII text, an image, sound etc.) Allocating different gopher document
types to different PEM content-domains will help the user agent by giving it
advance warning of what the message will contain. (In particular, it will enable
the user agent to determine whether it is capable of rendering the message
without actually retrieving it).
Optionally, the gopher user agent may also store the certificates from the
PEM header in a local cache. User agents may always do this, never do this,
or prompt the user as to whether particular certificates should be cached.
3.2 CRL
When directed by the user to retrieve a document of type CRL, the gopher user
agent should retrieve the document and then submit it for normal PEM
processing as described in RFC 1421 and RFC 1424. If processing is
successful, it should then indicate to the user the Distinguished Name(s) of
the certification authorities whose CRLs where retrieved.
The gopher agent may then store the certificates and CRLs from the PEM header
in a local cache. Indeed, the sole point of this procedure is to update the
local cache. User agents may update the local cache automatically or query the
user as to whether to do so. If a security error was detected during PEM
processing, then the cache should not be updated.
4. Server Procedures
4.1 MIC-CLEAR and MIC-ONLY
Servers may store PEM messages of these types as files, and supply them to
clients on demand. No cryptographic processing or understanding of the PEM
message format is necessary at the server.
It may be desirable for gopher servers to offer the same text as both a PEM
message and an ordinary gopher text file, while only storing a single copy
of the text. To do this, the server can store the PEM message in a file.
When asked for it as a PEM message, the server supplies the entire PEM message.
When asked for it as an ordinary file, the server removes the PEM header,
decodes the base-64 encoding (if the type is MIC-ONLY) and returns the result
to the client. Again, no cryptographic processing is necessary at the server,
although it does have to understand the PEM message format.
Similarly, gopher servers can offer the same text as a text file, a compressed
text file and a PEM message while only storing the PEM header and a compressed
version of the message body on disc.
4.2 CRL
Servers may store PEM messages of these types as files, and supply them to
clients on demand.
However, as CRLs become out of date and are re-issued at regular intervals
(typically a few days or weeks), gopher servers may treat these messages
specially.
Examples:
(a) A gopher server may periodically send PEM CRL-RETRIEVAL-REQUEST messages
to a CRL server, and automatically incorporate the result into gopher-space.
If this is done, it is recommended that the gopher server apply normal PEM
processing to new CRL messages, to check that they are valid.
(b) A gopher server may contact an X.500 Directory service, read the entry
of a certification authority, and convert the result into a PEM CRL message.
This may either be done periodically and the result stored, or performed
whenever a user requests a CRL document. In either case, it is recommended
that the gopher server apply normal PEM processing to the constructed CRL
message to ensure that it is valid.
NOTE: PEM processing involves an element of security policy. That is, whether
a PEM message is deemed to be valid or not depends on not just what is in it,
but on whether or not the entity doing the checking *trusts* the certification
authorities who issued the certificates attached to the message. A gopher server
cannot, in general, know who the gopher client trusts. Thus, gopher servers
which check CRL messages should do so with respect to a security policy in
which all known Policy CAs are trusted. This will eliminate obviously bogus
or malformed messages, whilst leaving the final determination of validity
up to the gopher client.
5. What's the point?
5.1 Gopher use of PEM
Storing documents as PEM messages enables the gopher client to detect
if the document has been modified:
a) in transit across the network from the gopher server
b) while being stored by the gopher server
c) in transit from the document author to the gopher server (by whatever
means)
Thus, it gives the user a high degree of assurance that the document they are
looking at is the same as the one the author wrote. As more information
becomes electronic, it is becoming increasingly hard to tell what is genuine
and what is a fake. For example, many White House press releases are widely
circulated on the net. It is extremely easy and tempting for a practical
joker to create spoof press releases that look extremely convincing. The
same applies (with slightly less attraction for hackers) to the countless
thousands of other public documents on the net.
Some caveats are in order:
(a) Signature does not prove authorship. Anyone can take a document written
by someone else and put their own PEM signature on it.
(b) It's the name in the PEM header that is checked, not the name on the
front page of the document. Display both to the user, so the user can
check they're the same! (This can't be done automatically as a program
can't easily determine which part of the text on the front page is the
author's name).
(c) Knowing that someone wrote something is not the same as knowing that it's
*true*. Don't believe everything you read on the net...
(d) This protocol doesn't provide any protection for gopher menus. Thus,
there is no guarantee that the document you got is the one you asked for.
However, as documents tend to be self-identifying (e.g. they have a title
at the front) this may not be a problem. (Hope springs eternal)
5.2 PEM use of Gopher
In order to send a PEM message to someone, you need to get hold of their
certificate somehow. In the OSI world, the way to do this is by using the
OSI Directory Service. While OSI Directories are now widely deployed in the
more civilised parts of the Internet, some technological backwaters do not
yet have access. Gopher provides a low-tech alternative to the OSI
directory; it's simpler, quicker, and it fits into the available memory on
a typical Apple Mac...