
 =============
 INTERNET NEWS
 =============

 PRIVACY ENHANCED MAIL - A STANDARD FOR ENCRYPTING INTERNET E-MAIL
 -----------------------------------------------------------------

Part of the magic of the global e-mail network built around the Internet is a
sort of least common denominator set of standards that allow various levels
of connectivity between machines that have little else in common. DOS, UNIX,
Macintosh, VMS, SunOS and other operating systems don't actually even use
precisely the same version of the American Standard Code for Information
Interchange (ASCII) character set, yet they can all send and receive a rude
form of electronic mail under Simple Mail Transfer Protocol or SMTP.
Additionally, they can share files, perform remote logins, and actually run
applications on each other to varying degrees.

The basis for all of this is a system of standards termed Requests For
Comment or RFC's. These are simply documents produced usually by small
committees of individuals collaborating electronically to iron out some of
the technical vagaries of linking one computer to another in the night.
Broadly, they function under the umbrella of the Internet Engineering Task
Force or IETF. Currently, most of this type of work falls under the auspices
of a fairly recently developed group called the Internet Society started by
Vinton Cerf. Sub-committees under the IETF work on draft documents which are
then submitted for publication as RFCs. There are currently over 1400 RFCs
available covering all aspects of Internet connectivity.

The basic format of an electronic mail message on the Internet is defined in
an RFC written by David Crocker and released August 13, 1982. RFC0822 defines
the format and nature of the ASCII text fields appearing in the header of an
Internet message. All of those DATE, SUBJECT, REPLY-TO, FROM, TO,
FORWARDED-FROM and other fields are described in this document. And actually,
the text body of an RFC0822 compliant message can be anything at all. Most of
the mail-agent software operating on all the diverse systems passing Internet
mail treat the information in this loosely defined message header
approximately the same way.

In recent years, there has been some movement toward making further
definitions regarding the types of data appearing in the message body of an
RFC0822 message. In 1982, ASCII text was about all that mattered. In 1992,
developers were eager to include binary files, sound recordings, page layout
output with fonts, and even video in electronic mail.

And so in 1992, largely due to the work of N. Borenstein of Bellcore and N.
Freed of Innosoft, a draft proposal was put together for Multipurpose
Internet Mail Extensions (MIME) noting Mechanisms for Specifying and
Describing the Format of Internet Message Bodies. This was published in June
of 1992 as RFC1341. RFC1342-1344 further detailed matters such as gateway
implications of the new standard, use of non-ASCII characters in headers, and
user agents. These standards don't actually replace RFC0822, but more
accurately augment it by defining elements appearing in the message body.

The MIME standard has gained some legs with dozens of e-mail program vendors
announcing at least partial compliance with MIME. The most notable advantage
of MIME is that it establishes a standard means of enclosing binary file
attachments, although there is also some immediate interest in including
Postscript documents. Ultimately, it will offer a path to include voicemail,
video, graphic images, and more in electronic mail.

Because of the wantonly open architecture of the Internet, many mail users
are concerned about the privacy of their communications. Mail generally flows
across any number of intermediate systems on the way to delivery in ordinary
ASCII text files that virtually any system administrator along the way can
look into with a standard editor and read with no one being the wiser.
There's no particular reason for them to do so, but the only privacy really
afforded is the fact that your message is poorly identified and traveling in
a river of thousands of others. For some, this is uncomfortably insecure. A
number of underground groups have begun experiments with data encryption of
e-mail using a freely distributed program titled Pretty Good Privacy.

Over the past year, the Privacy and Security Research Group (PSRG) of the
IRTF and the PEM Working Group of the Internet Engineering Task Force has
been developing a standard to address the security of electronic mail. And in
February, 1993, the IETF published a set of four RFCs describing a standard
titled Privacy Enhancement for Internet Electronic Mail (informally known as
Privacy Enhanced Mail or PEM) to establish a standard for encrypting
electronic mail using public key encryption techniques. The standard actually
also covers key authentication, certificates, and digital signatures that may
be key to performing such security sensitive transactions as transferring
funds electronically, contracts, agreements, and other communications that
require validation of who sent what to whom.

RFC1421 is titled Privacy Enhancement for Internet Electronic Mail - Part I:
Message Encryption and Authentication Procedures. Written by J. Linn, this
document describes the overall process of public key and private key
encryption of messages.

RFC1422 is titled Privacy Enhancement for Internet Electronic Mail - Part II:
Certificate-Based Key Management. Written by S. Kent, this document defines a
supporting key management architecture and infrastructure, based on
public-key certificate techniques, to provide keying information to message
originators and recipients.

RFC1423 is titled Privacy Enhancement for Internet Electronic Mail - Part
III: Algorithms, Modes, and Identifiers. Written by D. Balenson, this
document describes the encryption technology used and  references documents
you can use to develop applications. PEM allows for both the Data Encryption
Standard (DES) favored by the National Institute of Science and Technology
and the RSA algorithms patented by MIT and licensed by Public Key Partners.
This use of a patented encryption algorithm and the  requirement for
licensing through PKP is the most controversial element of PEM.

RFC1424 is titled Privacy Enhancement for Internet Electronic Mail - Part IV:
Key Certification and Related Services. Written by B. Kaliski, this document
describes three types of service in support of Internet Privacy-Enhanced
Mail: key certification, certificate-revocation list (CRL) storage, and CRL
retrieval. Such services are among those required of an RFC 1422
certification authority.

The Internet Society will actually administer the certification-authority for
the public key system. Basically, they will designate other entities who act
as a registry and certification authority for public keys.

Apple Computer, Inc. has been working on public key cryptography since 1991
and they immediately announced that PEM's digital signature feature will be
incorporated into the Macintosh operating system later this year.

PEM actually works with RFC0822 messages. There is a draft document dealing
with using PEM with MIME titled draft-ietf-pem-mime-00.txt available at
cnri.reston.va.us. Written by Marshall Rose, Ned Freed, and Stephen D.
Crocker, (crocker@tis.com), it goes into some detail on using PEM
cryptography within MIME messages.

For those interested in developing MIME or PEM features in their electronic
mail software, the RFCs are freely available. Anyone with ftp access can ftp
nic.ddn.mil and will find all the RFCs in the subdirectory /rfc. But you can
also have RFCs e-mailed to you from several mail servers that deliver the
documents by electronic mail. Send an electronic mail message to
RFC-INFO@ISI.EDU. In the body of the message enter the following lines to
retrieve RFC0822 for example:

 Retrieve: RFC
 Doc-ID: RFC0822

The full text of the document will be e-mailed to your mail box.Similarly,
you can send an e-mail message to MAIL-SERVER@NISC.SRI .COM.

 In the body of the message, enter the line:
 send rfc0822

We have packaged all these RFCs to make available on the Boardwatch BBS in
the Internet file area under PEM-RFC.ZIP and MIME-RFC.ZIP.

