In response to requests from many folks, we have drafted a revision to
RFC 1421 and submitted it to the ID drafts directory as
draft-rsadsi-pem-message-00.txt. This revision mainly addresses the
concerns raised on pem-dev for opening up PEM for non-hierarchical
trust models while maintainly a high degree of compatibility with the
existing PEM RFC 1422 hierarchical trust model.
Briefly, there are two main changes:
1. The use of Originator-Certificate is required in outgoing messages.
Originator-ID-Asymmetric is still supported in incoming messages for
compatibility. The use of a self-signed certificate in the
Originator-Cerificate field is explicitly permitted.
2. A new field, Recipient-Key-Asymmetric, is proposed as a replacement
for Recipient-ID-Asymmetric. The Recipient-Key-Asymmetric field is
used to identify recipients by public key. Recipient-ID-Asymmetric is
still supported for compatibility.
Please consider adding this to the agenda at the upcoming IETF
meeting. If there is enough interest, one of us can probably attend
to answer questions in person.
Cheers,
Steve Dusse
Jeff Thompson
---------------- cut here ------- ------
Network Working Group S. Dusse, J. Thompson
INTERNET-DRAFT [PEM Message Procedures]
Obsoletes: 1421 March 1994
draft-rsadsi-pem-message-00.txt
Privacy Enhancement for Internet Electronic Mail:
Part I: Message Encryption and Authentication Procedures
Status of this Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months. Internet-Drafts may be updated, replaced, or obsoleted by
other documents at any time. It is not appropriate to use Internet-
Drafts as reference material or to cite them other than as a
"working draft" or "work in progress."
To learn the current status of any Internet-Draft, please check
the 1id-abstracts.txt listing contained in the Internet-Drafts
Shadow Directories on ds.internic.net, nic.nordu.net,
ftp.isi.edu, or munnari.oz.au.
Acknowledgements
This document is a revision of RFC 1421, written by John Linn.
1. Executive Summary
This document defines message encryption and authentication
procedures, in order to provide privacy-enhanced mail (PEM) services
for electronic mail transfer in the Internet. It is intended to
become one member of a related set of four RFCs. The procedures
defined in the current document are intended to be compatible with a
wide range of key management approaches, including both symmetric
(secret-key) and asymmetric (public-key) approaches for encryption
of data encrypting keys. Use of symmetric cryptography for message
text encryption and/or integrity check computation is anticipated.
RFC 1422 specifies supporting key management mechanisms based on the
use of public-key certificates. RFC 1423 specifies algorithms,
modes, and associated identifiers relevant to the current document
and to RFC 1422. RFC 1424 provides details of paper and electronic
formats and procedures for the key management infrastructure being
established in support of these services.
Privacy enhancement services (confidentiality, authentication,
message integrity assurance, and non-repudiation of origin) are
offered through the use of end-to-end cryptography between
originator and recipient processes at or above the User Agent level.
Dusse, Thompson Expires: September 1994 [Page 1]
Internet-Draft PEM Message Procedures March 1994
No special processing requirements are imposed on the Message
Transfer System at endpoints or at intermediate relay sites. This
approach allows privacy enhancement facilities to be incorporated
selectively on a site-by-site or user-by-user basis without impact
on other Internet entities. Interoperability among heterogeneous
components and mail transport facilities is supported.
The current specification's scope is confined to PEM processing
procedures for the RFC-822 textual mail environment, and defines the
Content-Domain indicator value "RFC822" to signify this usage.
Follow-on work in integration of PEM capabilities with other
messaging environments (e.g., MIME) is anticipated and will be
addressed in separate and/or successor documents, at which point
additional Content-Domain indicator values will be defined.
2. Terminology
For descriptive purposes, this document uses some terms defined in
the OSI X.400 Message Handling System Model per the CCITT
Recommendations. This section replicates a portion of (1984) X.400's
Section 2.2.1, "Description of the MHS Model: Overview" in order to
make the terminology clear to readers who may not be familiar with
the OSI MHS Model.
In the [MHS] model, a user is a person or a computer application. A
user is referred to as either an originator (when sending a message)
or a recipient (when receiving one). MH Service elements define the
set of message types and the capabilities that enable an originator
to transfer messages of those types to one or more recipients.
An originator prepares messages with the assistance of his or her
User Agent (UA). A UA is an application process that interacts with
the Message Transfer System (MTS) to submit messages. The MTS
delivers to one or more recipient UAs the messages submitted to it.
Functions performed solely by the UA and not standardized as part of
the MH Service elements are called local UA functions.
The MTS is composed of a number of Message Transfer Agents (MTAs).
Operating together, the MTAs relay messages and deliver them to the
intended recipient UAs, which then make the messages available to
the intended recipients.
The collection of UAs and MTAs is called the Message Handling System
(MHS). The MHS and all of its users are collectively referred to as
the Message Handling Environment.
3. Services, Constraints, and Implications
This document defines mechanisms to enhance privacy for electronic
mail transferred in the Internet. The facilities discussed in this
Dusse, Thompson Expires: September 1994 [Page 2]
Internet-Draft PEM Message Procedures March 1994
document provide privacy enhancement services on an end-to-end basis
between originator and recipient processes residing at the UA level
or above. No privacy enhancements are offered for message fields
which are added or transformed by intermediate relay points between
PEM processing components.
If an originator elects to perform PEM processing on an outbound
message, all PEM-provided security services are applied to the PEM
message's body in its entirety; selective application to portions of
a PEM message is not supported. Authentication, integrity, and (when
asymmetric key management is employed) non-repudiation of origin
services are applied to all PEM messages; confidentiality services
are optionally selectable.
In keeping with the Internet's heterogeneous constituencies and
usage modes, the measures defined here are applicable to a broad
range of Internet hosts and usage paradigms. In particular, it is
worth noting the following attributes:
1. The mechanisms defined in this document are not
restricted to a particular host or operating system, but
rather allow interoperability among a broad range of
systems. All privacy enhancements are implemented at
the application layer, and are not dependent on any
privacy features at lower protocol layers.
2. The defined mechanisms are compatible with non-enhanced
Internet components. Privacy enhancements are
implemented in an end-to-end fashion which does not
impact mail processing by intermediate relay hosts which
do not incorporate privacy enhancement facilities. It
is necessary, however, for a message's originator to be
cognizant of whether a message's intended recipient
implements privacy enhancements, in order that encoding
and possible encryption will not be performed on a
message whose destination is not equipped to perform
corresponding inverse transformations. (Section
4.6.1.1.3 of this document describes a PEM message type
("MIC-CLEAR") which represents a signed, unencrypted PEM
message in a form readable without PEM processing
capabilities yet validatable by PEM-equipped
recipients.)
3. The defined mechanisms are compatible with a range of
mail transport facilities (MTAs). Within the Internet,
electronic mail transport is effected by a variety of
SMTP [2] implementations. Certain sites, accessible via
SMTP, forward mail into other mail processing
environments (e.g., USENET, CSNET, BITNET). The privacy
enhancements must be able to operate across the SMTP
realm; it is desirable that they also be compatible with
Dusse, Thompson Expires: September 1994 [Page 3]
Internet-Draft PEM Message Procedures March 1994
protection of electronic mail sent between the SMTP
environment and other connected environments.
4. The defined mechanisms are compatible with a broad range
of electronic mail user agents (UAs). A large variety
of electronic mail user agent programs, with a
corresponding broad range of user interface paradigms,
is used in the Internet. In order that electronic mail
privacy enhancements be available to the broadest
possible user community, selected mechanisms should be
usable with the widest possible variety of existing UA
programs. For purposes of pilot implementation, it is
desirable that privacy enhancement processing be
incorporable into a separate program, applicable to a
range of UAs, rather than requiring internal
modifications to each UA with which PEM services are to
be provided.
5. The defined mechanisms allow electronic mail privacy
enhancement processing to be performed on personal
computers (PCs) separate from the systems on which UA
functions are implemented. Given the expanding use of
PCs and the limited degree of trust which can be placed
in UA implementations on many multi-user systems, this
attribute can allow many users to process PEM with a
higher assurance level than a strictly UA-integrated
approach would allow.
6. The defined mechanisms support privacy protection of
electronic mail addressed to mailing lists (distribution
lists, in ISO parlance).
7. The mechanisms defined within this document are
compatible with a variety of supporting key management
approaches, including (but not limited to) manual pre-
distribution, centralized key distribution based on
symmetric cryptography, and the use of public-key
certificates per RFC 1422. Different key management
mechanisms may be used for different recipients of a
multicast message. For two PEM implementations to
interoperate, they must share a common key management
mechanism; support for the mechanism defined in RFC 1422
is strongly encouraged. However, the use of the
Recipient-Key-Asymmetric field and a self-signed
certificate as the Originator-Certificate permit
privacy-enhanced messaging independent of an established
certificate hierarchy.
In order to achieve applicability to the broadest possible range of
Internet hosts and mail systems, and to facilitate pilot
implementation and testing without the need for prior and pervasive
modifications throughout the Internet, the following design
Dusse, Thompson Expires: September 1994 [Page 4]
Internet-Draft PEM Message Procedures March 1994
principles were applied in selecting the set of features specified
in this document:
1. This document's measures are restricted to implementation
at endpoints and are amenable to integration with
existing Internet mail protocols at the user agent (UA)
level or above, rather than necessitating modifications
to existing mail protocols or integration into the
message transport system (e.g., SMTP servers).
2. The set of supported measures enhances rather than
restricts user capabilities. Trusted implementations,
incorporating integrity features protecting software
from subversion by local users, cannot be assumed in
general. No mechanisms are assumed to prevent users
from sending, at their discretion, messages to which no
PEM processing has been applied. In the absence of such
features, it appears more feasible to provide facilities
which enhance user services (e.g., by protecting and
authenticating inter-user traffic) than to enforce
restrictions (e.g., inter-user access control) on user
actions.
3. The set of supported measures focuses on a set of
functional capabilities selected to provide significant
and tangible benefits to a broad user community. By
concentrating on the most critical set of services, we
aim to maximize the added privacy value that can be
provided with a modest level of implementation effort.
Based on these principles, the following facilities are provided:
1. disclosure protection,
2. originator authenticity,
3. message integrity measures, and
4. (if asymmetric key management is used) non-repudiation of
origin,
but the following privacy-relevant concerns are not addressed:
1. access control,
2. traffic flow confidentiality,
3. address list accuracy,
4. routing control,
Dusse, Thompson Expires: September 1994 [Page 5]
Internet-Draft PEM Message Procedures March 1994
5. issues relating to the casual serial reuse of PCs by
multiple users,
6. assurance of message receipt and non-deniability of
receipt,
7. automatic association of acknowledgments with the
messages to which they refer, and
8. message duplicate detection, replay prevention, or other
stream-oriented services
4. Processing of Messages
4.1 Message Processing Overview
This subsection provides a high-level overview of the components and
processing steps involved in electronic mail privacy enhancement
processing. Subsequent subsections will define the procedures in
more detail.
4.1.1 Types of Keys
A two-level keying hierarchy is used to support PEM transmission:
1. Data Encrypting Keys (DEKs) are used for encryption of
message text and (with certain choices among a set of
alternative algorithms) for computation of message
integrity check (MIC) quantities. In the asymmetric key
management environment, DEKs are also used to encrypt
the signed representations of MICs in PEM messages to
which confidentiality has been applied. DEKs are
generated individually for each transmitted message; no
predistribution of DEKs is needed to support PEM
transmission.
2. Interchange Keys (IKs) are used to encrypt DEKs for
transmission within messages. Ordinarily, the same IK
will be used for all messages sent from a given
originator to a given recipient over a period of time.
Each transmitted message includes a representation of
the DEK(s) used for message encryption and/or MIC
computation, encrypted under an individual IK per named
recipient. The representation is associated with
originator and recipient identifier fields (defined in
different forms so as to distinguish symmetric from
asymmetric cases), which allow each individual recipient
to identify the IK used to encrypt DEKs and/or MICs for
that recipient's use. Given an appropriate IK, a
Dusse, Thompson Expires: September 1994 [Page 6]
Internet-Draft PEM Message Procedures March 1994
recipient can decrypt the corresponding transmitted DEK
representation, yielding the DEK required for message
text decryption and/or MIC validation. The definition
of an IK differs depending on whether symmetric or
asymmetric cryptography is used for DEK encryption:
2a. When symmetric cryptography is used for DEK
encryption, an IK is a single symmetric key shared
between an originator and a recipient. In this
case, the same IK is used to encrypt MICs as well
as DEKs for transmission. Version/expiration
information and IA identification associated with
the originator and with the recipient must be
concatenated in order to fully qualify a symmetric
IK.
2b. When asymmetric cryptography is used, the IK
component used for DEK encryption is the public
component [8] of the recipient. The IK component
used for MIC encryption is the private component of
the originator, and therefore only one encrypted
MIC representation need be included per message,
rather than one per recipient. Each of these IK
components can be determined from recipient and
originator identifier fields, respectively.
4.1.2 Processing Procedures
When PEM processing is to be performed on an outgoing message, a DEK
is generated [1] for use in message encryption and (if a chosen MIC
algorithm requires a key) a variant of the DEK is formed for use in
MIC computation. DEK generation can be omitted for the case of a
message where confidentiality is not to be applied, unless a chosen
MIC computation algorithm requires a DEK. Other parameters (e.g.,
Initialization Vectors (IVs)) as required by selected encryption
algorithms are also generated.
One or more originator identifier fields are included in a PEM
message's encapsulated header to provide recipients with an
identification component for the IK(s) used for message processing.
All of a message's originator identifier fields are assumed to
correspond to the same principal; the facility for inclusion of
multiple such fields accomodates the prospect that different keys,
algorithms, and/or certification paths may be required for
processing by different recipients. When a message includes
recipients for which asymmetric key management is employed as well
as recipients for which symmetric key management is employed, a
separate originator identifier field precedes each set of
recipients.
Dusse, Thompson Expires: September 1994 [Page 7]
Internet-Draft PEM Message Procedures March 1994
In the symmetric case, per-recipient IK components are applied for
each individually named recipient in preparation of ENCRYPTED, MIC-
ONLY, and MIC-CLEAR messages. A corresponding "Recipient-ID-
Symmetric:" field, interpreted in the context of the most recent
preceding "Originator-ID-Symmetric:" field, serves to identify each
IK. In the asymmetric case, per-recipient IK components are applied
only for ENCRYPTED messages, are independent of originator-oriented
header elements, and are identified by "Recipient-Key-Asymmetric:"
or "Recipient-ID-Asymmetric:" fields. Each recipient identifier
field is followed by a "Key-Info:" field, which transfers the
message's DEK encrypted under the IK appropriate for the specified
recipient.
When symmetric key management is used for a given recipient, the
"Key-Info:" field following the corresponding "Recipient-ID-
Symmetric:" field also transfers the message's computed MIC,
encrypted under the recipient's IK. When asymmetric key management
is used, a "MIC-Info:" field associated with an "Originator-ID-
Asymmetric:" or "Originator-Certificate:" field carries the
message's MIC, asymmetrically signed using the private component of
the originator. If the PEM message is of type ENCRYPTED (as defined
in Section 4.6.1.1.1 of this document), the asymmetrically signed
MIC is symmetrically encrypted using the same DEK, algorithm,
encryption mode and other cryptographic parameters as used to
encrypt the message text, prior to inclusion in the "MIC-Info:"
field.
4.1.2.1 Processing Steps
A four-phase transformation procedure is employed in order to
represent encrypted message text in a universally transmissible form
and to enable messages encrypted on one type of host computer to be
decrypted on a different type of host computer. A plaintext message
is accepted in local form, using the host's native character set and
line representation. The local form is converted to a canonical
message text representation, defined as equivalent to the inter-SMTP
representation of message text. This canonical representation forms
the input to the MIC computation step (applicable to ENCRYPTED, MIC-
ONLY, and MIC-CLEAR messages) and the encryption process (applicable
to ENCRYPTED messages only).
For ENCRYPTED PEM messages, the canonical representation is padded
as required by the encryption algorithm, and this padded canonical
representation is encrypted. The encrypted text (for an ENCRYPTED
message) or the unpadded canonical form (for a MIC-ONLY message) is
then encoded into a printable form. The printable form is composed
of a restricted character set which is chosen to be universally
representable across sites, and which will not be disrupted by
processing within and between MTS entities. MIC-CLEAR PEM messages
omit the printable encoding step.
Dusse, Thompson Expires: September 1994 [Page 8]
Internet-Draft PEM Message Procedures March 1994
The output of the previous processing steps is combined with a set
of header fields carrying cryptographic control information. The
resulting PEM message is passed to the electronic mail system to be
included within the text portion of a transmitted message. There is
no requirement that a PEM message comprise the entirety of an MTS
message's text portion; this allows PEM-protected information to be
accompanied by (unprotected) annotations. It is also permissible
for multiple PEM messages (and associated unprotected text, outside
the PEM message boundaries) to be represented within the
encapsulated text of a higher-level PEM message. PEM message
signatures are forwardable when asymmetric key management is
employed; an authorized recipient of a PEM message with
confidentiality applied can reduce that message to a signed but
unencrypted form for forwarding purposes or can re-encrypt that
message for subsequent transmission.
When a PEM message is received, the cryptographic control fields
within its encapsulated header provide the information required for
each authorized recipient to perform MIC validation and decryption
of the received message text. For ENCRYPTED and MIC-ONLY messages,
the printable encoding is converted to a bitstring. Encrypted
portions of the transmitted message are decrypted. The MIC is
validated. Then, the recipient PEM process converts the canonical
representation to its appropriate local form.
4.1.2.2 Error Cases
A variety of error cases may occur and be detected in the course of
processing a received PEM message. The specific actions to be taken
in response to such conditions are local matters, varying as
functions of user preferences and the type of user interface
provided by a particular PEM implementation, but certain general
recommendations are appropriate. Syntactically invalid PEM messages
should be flagged as such, preferably with collection of diagnostic
information to support debugging of incompatibilities or other
failures. RFC 1422 defines specific error processing requirements
relevant to the certificate-based key management mechanisms defined
therein.
Syntactically valid PEM messages which yield MIC failures raise
special concern, as they may result from attempted attacks or forged
messages. As such, it is unsuitable to display their contents to
recipient users without first indicating the fact that the contents'
authenticity and integrity cannot be guaranteed and then receiving
positive user confirmation of such a warning. MIC-CLEAR messages
(discussed in Section 4.6.1.1.3 of this document) raise special
concerns, as MIC failures on such messages may occur for a broader
range of benign causes than are applicable to other PEM message
types.
Dusse, Thompson Expires: September 1994 [Page 9]
Internet-Draft PEM Message Procedures March 1994
4.2 Encryption Algorithms, Modes, and Parameters
For use in conjunction with this document, RFC 1423 defines the
appropriate algorithms, modes, and associated identifiers to be used
for encryption of message text with DEKs.
The mechanisms defined in this document incorporate facilities for
transmission of cryptographic parameters (e.g., pseudorandom
Initializing Vectors (IVs)) with PEM messages to which the
confidentiality service is applied, when required by symmetric
message encryption algorithms and modes specified in RFC 1423.
Certain operations require encryption of DEKs, MICs, and digital
signatures under an IK for purposes of transmission. A header
facility indicates the mode in which the IK is used for encryption.
RFC 1423 specifies encryption algorithm and mode identifiers and
minimum essential support requirements for key encryption
processing.
RFC 1422 specifies asymmetric, certificate-based key management
procedures based on CCITT Recommendation X.509 to support the
message processing procedures defined in this document. Support for
the key management approach defined in RFC 1422 is strongly
recommended. The message processing procedures can also be used
with symmetric key management, given prior distribution of suitable
symmetric IKs, but no current RFCs specify key distribution
procedures for such IKs.
4.3 Privacy Enhancement Message Transformations
4.3.1 Constraints
An electronic mail encryption mechanism must be compatible with the
transparency constraints of its underlying electronic mail
facilities. These constraints are generally established based on
expected user requirements and on the characteristics of anticipated
endpoint and transport facilities. An encryption mechanism must
also be compatible with the local conventions of the computer
systems which it interconnects. Our approach uses a
canonicalization step to abstract out local conventions and a
subsequent encoding step to conform to the characteristics of the
underlying mail transport medium (SMTP). The encoding conforms to
SMTP constraints. Section 4.5 of RFC 821 [2] details SMTP's
transparency constraints.
To prepare a message for SMTP transmission, the following
requirements must be met:
1. All characters must be members of the 7-bit ASCII
character set.
Dusse, Thompson Expires: September 1994 [Page 10]
Internet-Draft PEM Message Procedures March 1994
2. Text lines, delimited by the character pair <CR><LF>,
must be no more than 1000 characters long.
3. Since the string <CR><LF>.<CR><LF> indicates the end of a
message, it must not occur in text prior to the end of a
message.
Although SMTP specifies a standard representation for line
delimiters (ASCII <CR><LF>), numerous systems in the Internet use a
different native representation to delimit lines. For example, the
<CR><LF> sequences delimiting lines in mail inbound to UNIX systems
are transformed to single <LF>s as mail is written into local
mailbox files. Lines in mail incoming to record-oriented systems
(such as VAX VMS) may be converted to appropriate records by the
destination SMTP server [3]. As a result, if the encryption process
generated <CR>s or <LF>s, those characters might not be accessible
to a recipient UA program at a destination which uses different line
delimiting conventions. It is also possible that conversion between
tabs and spaces may be performed in the course of mapping between
inter-SMTP and local format; this is a matter of local option. If
such transformations changed the form of transmitted ciphertext,
decryption would fail to regenerate the transmitted plaintext, and a
transmitted MIC would fail to compare with that computed at the
destination.
The conversion performed by an SMTP server at a system with EBCDIC
as a native character set has even more severe impact, since the
conversion from EBCDIC into ASCII is an information-losing
transformation. In principle, the transformation function mapping
between inter-SMTP canonical ASCII message representation and local
format could be moved from the SMTP server up to the UA, given a
means to direct that the SMTP server should no longer perform that
transformation. This approach has a major disadvantage: internal
file (e.g., mailbox) formats would be incompatible with the native
forms used on the systems where they reside. Further, it would
require modification to SMTP servers, as mail would be passed to
SMTP in a different representation than it is passed at present.
4.3.2 Approach
Our approach to supporting PEM across an environment in which
intermediate conversions may occur defines an encoding for mail
which is uniformly representable across the set of PEM UAs
regardless of their systems' native character sets. This encoded
form is used (for specified PEM message types) to represent mail
text in transit from originator to recipient, but the encoding is
not applied to enclosing MTS headers or to encapsulated headers
inserted to carry control information between PEM UAs. The
encoding's characteristics are such that the transformations
anticipated between originator and recipient UAs will not prevent an
encoded message from being decoded properly at its destination.
Dusse, Thompson Expires: September 1994 [Page 11]
Internet-Draft PEM Message Procedures March 1994
Four transformation steps, described in the following four
subsections, apply to outbound PEM message processing:
4.3.2.1 Step 1: Local Form
This step is applicable to PEM message types ENCRYPTED, MIC-ONLY,
and MIC-CLEAR. The message text is created in the system's native
character set, with lines delimited in accordance with local
convention.
4.3.2.2 Step 2: Canonical Form
This step is applicable to PEM message types ENCRYPTED, MIC-ONLY,
and MIC-CLEAR. The message text is converted to a universal
canonical form, similar to the inter-SMTP representation [4] as
defined in RFC 821 [2] and RFC 822 [5]. The procedures performed in
order to accomplish this conversion are dependent on the
characteristics of the local form and so are not specified in this
document.
PEM canonicalization assures that the message text is represented
with the ASCII character set and "<CR><LF>" line delimiters, but
does not perform the dot-stuffing transformation discussed in RFC
821, Section 4.5.2. Since a message is converted to a standard
character set and representation before encryption, a transferred
PEM message can be decrypted and its MIC can be validated at any
type of destination host computer. Decryption and MIC validation is
performed before any conversions which may be necessary to transform
the message into a destination-specific local form.
4.3.2.3 Step 3: Authentication and Encryption
Authentication processing is applicable to PEM message types
ENCRYPTED, MIC-ONLY, and MIC-CLEAR. The canonical form is input to
the selected MIC computation algorithm in order to compute an
integrity check quantity for the message. No padding is added to
the canonical form before submission to the MIC computation
algorithm, although certain MIC algorithms will apply their own
padding in the course of computing a MIC.
Encryption processing is applicable only to PEM message type
ENCRYPTED. RFC 1423 defines the padding technique used to support
encryption of the canonically-encoded message text.
4.3.2.4 Step 4: Printable Encoding
This printable encoding step is applicable to PEM message types
ENCRYPTED and MIC-ONLY. The same processing is also employed in
Dusse, Thompson Expires: September 1994 [Page 12]
Internet-Draft PEM Message Procedures March 1994
representation of certain specifically identified PEM encapsulated
header field quantities as cited in Section 4.6. Proceeding from
left to right, the bit string resulting from step 3 is encoded into
characters which are universally representable at all sites, though
not necessarily with the same bit patterns (e.g., although the
character "E" is represented in an ASCII-based system as hexadecimal
45 and as hexadecimal C5 in an EBCDIC-based system, the local
significance of the two representations is equivalent).
A 64-character subset of International Alphabet IA5 is used,
enabling 6 bits to be represented per printable character. (The
proposed subset of characters is represented identically in IA5 and
ASCII.) The character "=" signifies a special processing function
used for padding within the printable encoding procedure.
To represent the encapsulated text of a PEM message, the encoding
function's output is delimited into text lines (using local
conventions), with each line except the last containing exactly 64
printable characters and the final line containing 64 or fewer
printable characters. (This line length is easily printable and is
guaranteed to satisfy SMTP's 1000-character transmitted line length
limit.) This folding requirement does not apply when the encoding
procedure is used to represent PEM header field quantities; Section
4.6 discusses folding of PEM encapsulated header fields.
The encoding process represents 24-bit groups of input bits as
output strings of 4 encoded characters. Proceeding from left to
right across a 24-bit input group extracted from the output of step
3, each 6-bit group is used as an index into an array of 64
printable characters. The character referenced by the index is
placed in the output string. These characters, identified in Table
1, are selected so as to be universally representable, and the set
excludes characters with particular significance to SMTP (e.g., ".",
"<CR>", "<LF>").
Special processing is performed if fewer than 24 bits are available
in an input group at the end of a message. A full encoding quantum
is always completed at the end of a message. When fewer than 24
input bits are available in an input group, zero bits are added (on
the right) to form an integral number of 6-bit groups. Output
character positions which are not required to represent actual input
data are set to the character "=". Since all canonically encoded
output is an integral number of octets, only the following cases can
arise: (1) the final quantum of encoding input is an integral
multiple of 24 bits; here, the final unit of encoded output will be
an integral multiple of 4 characters with no "=" padding, (2) the
final quantum of encoding input is exactly 8 bits; here, the final
unit of encoded output will be two characters followed by two "="
padding characters, or (3) the final quantum of encoding input is
exactly 16 bits; here, the final unit of encoded output will be
three characters followed by one "=" padding character.
Dusse, Thompson Expires: September 1994 [Page 13]
Internet-Draft PEM Message Procedures March 1994
Value Encoding Value Encoding Value Encoding Value Encoding
0 A 17 R 34 i 51 z
1 B 18 S 35 j 52 0
2 C 19 T 36 k 53 1
3 D 20 U 37 l 54 2
4 E 21 V 38 m 55 3
5 F 22 W 39 n 56 4
6 G 23 X 40 o 57 5
7 H 24 Y 41 p 58 6
8 I 25 Z 42 q 59 7
9 J 26 a 43 r 60 8
10 K 27 b 44 s 61 9
11 L 28 c 45 t 62 +
12 M 29 d 46 u 63 /
13 N 30 e 47 v
14 O 31 f 48 w (pad) =
15 P 32 g 49 x
16 Q 33 h 50 y
Printable Encoding Characters
Table 1
4.3.2.5 Summary of Transformations
In summary, the outbound message is subjected to the following
composition of transformations (or, for some PEM message types, a
subset thereof):
Transmit_Form = Encode(Encrypt(Canonicalize(Local_Form)))
The inverse transformations are performed, in reverse order, to
process inbound PEM messages:
Local_Form = DeCanonicalize(Decipher(Decode(Transmit_Form)))
Note that the local form and the functions to transform messages to
and from canonical form may vary between the originator and
recipient systems without loss of information.
4.4 Encapsulation Mechanism
The encapsulation techniques defined in RFC-934 [6] are adopted for
encapsulation of PEM messages within separate enclosing MTS messages
carrying associated MTS headers. This approach offers a number of
advantages relative to a flat approach in which certain fields
within a single header are encrypted and/or carry cryptographic
control information. As far as the MTS is concerned, the entirety
of a PEM message will reside in an MTS message's text portion, not
the MTS message's header portion. Encapsulation provides generality
and segregates fields with user-to-user significance from those
Dusse, Thompson Expires: September 1994 [Page 14]
Internet-Draft PEM Message Procedures March 1994
transformed in transit. All fields inserted in the course of
encryption/authentication processing are placed in the encapsulated
header. This facilitates compatibility with mail handling programs
which accept only text, not header fields, from input files or from
other programs.
The encapsulation techniques defined in RFC-934 are consistent with
existing Internet mail forwarding and bursting mechanisms. These
techniques are designed so that they may be used in a nested manner.
The encapsulation techniques may be used to encapsulate one or more
PEM messages for forwarding to a third party, possibly in
conjunction with interspersed (non-PEM) text which serves to
annotate the PEM messages.
Two encapsulation boundaries (EB's) are defined for delimiting
encapsulated PEM messages and for distinguishing encapsulated PEM
messages from interspersed (non-PEM) text. The pre-EB is the string
"-----BEGIN PRIVACY-ENHANCED MESSAGE-----", indicating that an
encapsulated PEM message follows. The post-EB is either (1) another
pre-EB indicating that another encapsulated PEM message follows, or
(2) the string "-----END PRIVACY-ENHANCED MESSAGE-----" indicating
that any text that immediately follows is non-PEM text. A special
point must be noted for the case of MIC-CLEAR messages, the text
portions of which may contain lines which begin with the "- "
character and which are therefore subject to special processing per
RFC-934 forwarding procedures. When the string "-" must be
prepended to such a line in the course of a forwarding operation in
order to distinguish that line from an encapsulation boundary, MIC
computation is to be performed prior to prepending the "- " string.
Figure 1 depicts the encapsulation of a single PEM message.
This document places no a priori limits on the depth to which such
encapsulation may be nested nor on the number of PEM messages which
may be grouped in this fashion at a single nesting level for
forwarding. A implementation compliant with this document must not
preclude a user from submitting or receiving PEM messages which
exploit this encapsulation capability. However, no specific
requirements are levied upon implementations with regard to how this
capability is made available to the user. Thus, for example, a
compliant PEM implementation is not required to automatically detect
and process encapsulated PEM messages.
In using this encapsulation facility, it is important to note that
it is inappropriate to forward directly to a third party a message
that is ENCRYPTED because recipients of such a message would not
have access to the DEK required to decrypt the message. Instead,
the user forwarding the message must transform the ENCRYPTED message
into a MIC-ONLY or MIC-CLEAR form prior to forwarding. Thus, in
order to comply with this document, a PEM implementation must
provide a facility to enable a user to perform this transformation,
while preserving the MIC associated with the original message.
Dusse, Thompson Expires: September 1994 [Page 15]
Internet-Draft PEM Message Procedures March 1994
If a user wishes PEM-provided confidentiality protection for
transmitted information, such information must occur in the
encapsulated text of an ENCRYPTED PEM message, not in the enclosing
MTS header or PEM encapsulated header. If a user wishes to avoid
disclosing the actual subject of a message to unintended parties, it
is suggested that the enclosing MTS header contain a "Subject:"
field indicating that "Encrypted Mail Follows".
Encapsulated Message
Pre-Encapsulation Boundary (Pre-EB)
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Encapsulated Header Portion
(Contains encryption control fields inserted in
plaintext. Examples include "DEK-Info:" and "Key-Info:".
Note that, although these control fields have line-
oriented representations similar to RFC 822 header
fields, the set of fields valid in this context is
disjoint from those used in RFC 822 processing.)
Blank Line
(Separates Encapsulated Header from subsequent
Encapsulated Text Portion)
Encapsulated Text Portion
(Contains message data encoded as specified in Section
4.3.)
Post-Encapsulation Boundary (Post-EB)
-----END PRIVACY-ENHANCED MESSAGE-----
Encapsulated Message Format
Figure 1
If an integrity-protected representation of information which occurs
within an enclosing header (not necessarily in the same format as
that in which it occurs within that header) is desired, that data
can be included within the encapsulated text portion in addition to
its inclusion in the enclosing MTS header. For example, an
originator wishing to provide recipients with a protected indication
of a message's position in a series of messages could include within
the encapsulated text a copy of a timestamp or message counter value
possessing end-to-end significance and extracted from an enclosing
MTS header field. (Note: mailbox specifiers as entered by end users
incorporate local conventions and are subject to modification at
intermediaries, so inclusion of such specifiers within encapsulated
text should not be regarded as a suitable alternative to the
authentication semantics defined in RFC 1422 and based on X.500
Distinguished Names.) The set of header information (if any)
included within the encapsulated text of messages is a local matter,
Dusse, Thompson Expires: September 1994 [Page 16]
Internet-Draft PEM Message Procedures March 1994
and this document does not specify formatting conventions to
distinguish replicated header fields from other encapsulated text.
4.5 Mail for Mailing Lists
When mail is addressed to mailing lists, two different methods of
processing can be applicable: the IK-per-list method and the IK-per-
recipient method. Hybrid approaches are also possible, as in the
case of IK-per-list protection of a message on its path from an
originator to a PEM-equipped mailing list exploder, followed by IK-
per-recipient protection from the exploder to individual list
recipients.
If a message's originator is equipped to expand a destination
mailing list into its individual constituents and elects to do so
(IK-per-recipient), the message's DEK (and, in the symmetric key
management case, MIC) will be encrypted under each per-recipient IK
and all such encrypted representations will be incorporated into the
transmitted message. Note that per-recipient encryption is required
only for the relatively small DEK and MIC quantities carried in the
"Key-Info:" field, not for the message text which is, in general,
much larger. Although more IKs are involved in processing under the
IK-per-recipient method, the pairwise IKs can be individually
revoked and possession of one IK does not enable a successful
masquerade of another user on the list.
If a message's originator addresses a message to a list name or
alias, use of an IK associated with that name or alias as a entity
(IK-per-list), rather than resolution of the name or alias to its
constituent destinations, is implied. Such an IK must, therefore, be
available to all list members. Unfortunately, it implies an
undesirable level of exposure for the shared IK, and makes its
revocation difficult. Moreover, use of the IK-per-list method
allows any holder of the list's IK to masquerade as another
originator to the list for authentication purposes.
Pure IK-per-list key management in the asymmetric case (with a
common private key shared among multiple list members) is
particularly disadvantageous in the asymmetric environment, as it
fails to preserve the forwardable authentication and non-repudiation
characteristics which are provided for other messages in this
environment. Use of a hybrid approach with a PEM-capable exploder
is therefore particularly recommended for protection of mailing list
traffic when asymmetric key management is used; such an exploder
would reduce (per discussion in Section 4.4 of this document)
incoming ENCRYPTED messages to MIC-ONLY or MIC-CLEAR form before
forwarding them (perhaps re-encrypted under individual, per-
recipient keys) to list members.
Dusse, Thompson Expires: September 1994 [Page 17]
Internet-Draft PEM Message Procedures March 1994
4.6 Summary of Encapsulated Header Fields
This section defines the syntax and semantics of the encapsulated
header fields to be added to messages in the course of privacy
enhancement processing.
The fields are presented in three groups. Normally, the groups will
appear in encapsulated headers in the order in which they are shown,
though not all fields in each group will appear in all messages.
The following figures show the appearance of small example
encapsulated messages. Figure 2 assumes the use of symmetric
cryptography for key management. Figure 3 illustrates an example
encapsulated ENCRYPTED message in which asymmetric key management is
used.
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,ENCRYPTED
Content-Domain: RFC822
DEK-Info: DES-CBC,F8143EDE5960C597
Originator-ID-Symmetric: linn(_at_)zendia(_dot_)enet(_dot_)dec(_dot_)com,,
Recipient-ID-Symmetric:
linn(_at_)zendia(_dot_)enet(_dot_)dec(_dot_)com,ptf-kmc,3
Key-Info: DES-ECB,RSA-MD2,9FD3AAD2F2691B9A,
B70665BB9BF7CBCDA60195DB94F727D3
Recipient-ID-Symmetric: pem-dev(_at_)tis(_dot_)com,ptf-kmc,4
Key-Info: DES-ECB,RSA-MD2,161A3F75DC82EF26,
E2EF532C65CBCFF79F83A2658132DB47
LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M
8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk
J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot
dXd/H5LMDWnonNvPCwQUHt==
-----END PRIVACY-ENHANCED MESSAGE-----
Example Encapsulated Message (Symmetric Case)
Figure 2
Figure 4 illustrates an example encapsulated MIC-ONLY message in
which asymmetric key management is used; since no per-recipient keys
are involved in preparation of asymmetric-case MIC-ONLY messages,
this example should be processable for test purposes by arbitrary
PEM implementations.
Fully-qualified domain names (FQDNs) for hosts, appearing in the
mailbox names found in entity identifier subfields of "Originator-
ID-Symmetric:" and "Recipient-ID-Symmetric:" fields, are processed
in a case-insensitive fashion. Unless specified to the contrary,
other field arguments (including the user name components of mailbox
names) are to be processed in a case-sensitive fashion.
In most cases, numeric quantities are represented in header fields
as contiguous strings of hexadecimal digits, where each digit is
represented by a character from the ranges "0"-"9" or upper case
Dusse, Thompson Expires: September 1994 [Page 18]
Internet-Draft PEM Message Procedures March 1994
"A"-"F". Since public-key certificates and quantities encrypted
using asymmetric algorithms are large in size, use of a more space-
efficient encoding technique is appropriate for such quantities, and
the encoding mechanism defined in Section 4.3.2.4 of this document,
representing 6 bits per printed character, is adopted for this
purpose.
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,ENCRYPTED
Content-Domain: RFC822
DEK-Info: DES-CBC,BFF968AA74691AC1
Originator-Certificate:
MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGA1UEBhMCVVMxIDAeBgNV
BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDzAN
BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQxODM4MTdaFw05MzA5MDMxODM4MTZaMEUx
CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEU
MBIGA1UEAxMLVGVzdCBVc2VyIDEwWTAKBgRVCAEBAgICAANLADBIAkEAwHZHl7i+
yJcqDtjJCowzTdBJrdAiLAnSC+CnnjOJELyuQiBgkGrgIh3j8/x0fM+YrsyF1u3F
LZPVtzlndhYFJQIDAQABMA0GCSqGSIb3DQEBAgUAA1kACKr0PqphJYw1j+YPtcIq
iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2wfX5byMp2X3U/
5XUXGx7qusDgHQGs7Jk9W8CW1fuSWUgN4w==
Key-Info: RSA,
I3rRIGXUGWAF8js5wCzRTkdhO34PTHdRZY9Tuvm03M+NM7fx6qc5udixps2Lng0+
wGrtiUm/ovtKdinz6ZQ/aQ==
Issuer-Certificate:
MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGA1UEBhMCVVMxIDAeBgNV
BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDTAL
BgNVBAsTBFRMQ0EwHhcNOTEwOTAxMDgwMDAwWhcNOTIwOTAxMDc1OTU5WjBRMQsw
CQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4xDzAN
BgNVBAsTBkJldGEgMTEPMA0GA1UECxMGTk9UQVJZMHAwCgYEVQgBAQICArwDYgAw
XwJYCsnp6lQCxYykNlODwutF/jMJ3kL+3PjYyHOwk+/9rLg6X65B/LD4bJHtO5XW
cqAz/7R7XhjYCm0PcqbdzoACZtIlETrKrcJiDYoP+DkZ8k1gCk7hQHpbIwIDAQAB
MA0GCSqGSIb3DQEBAgUAA38AAICPv4f9Gx/tY4+p+4DB7MV+tKZnvBoy8zgoMGOx
dD2jMZ/3HsyWKWgSF0eH/AJB3qr9zosG47pyMnTf3aSy2nBO7CMxpUWRBcXUpE+x
EREZd9++32ofGBIXaialnOgVUn0OzSYgugiQ077nJLDUj0hQehCizEs5wUJ35a5h
MIC-Info: RSA-MD5,RSA,
UdFJR8u/TIGhfH65ieewe2lOW4tooa3vZCvVNGBZirf/7nrgzWDABz8w9NsXSexv
AjRFbHoNPzBuxwmOAFeA0HJszL4yBvhG
Recipient-Key-Asymmetric:
MHAwCgYEVQgBAQICArwDYgAwXwJYDNi3BbCOZY0FCRmtHi9l6dZhDpTnfBTBstEn
KI1/9QCugnBm+c1LsbTxy7v9566/JJ7n2AQbtO9XgDoE3CA7RWdW/KKdC+bq4Gs6
yTTBw1HDrJJcnBarGQIDAQAB
Key-Info: RSA,
O6BS1ww9CTyHPtS3bMLD+L0hejdvX6Qv1HK2ds2sQPEaXhX8EhvVphHYTjwekdWv
7x0Z3Jx2vTAhOYHMcqqCjA==
qeWlj/YJ2Uf5ng9yznPbtD0mYloSwIuV9FRYx+gzY+8iXd/NQrXHfi6/MhPfPF3d
jIqCJAxvld2xgqQimUzoS1a4r7kQQ5c/Iua4LqKeq3ciFzEv/MbZhA==
-----END PRIVACY-ENHANCED MESSAGE-----
Example Encapsulated ENCRYPTED Message (Asymmetric Case)
Figure 3
Dusse, Thompson Expires: September 1994 [Page 19]
Internet-Draft PEM Message Procedures March 1994
Encapsulated headers of PEM messages are folded using whitespace per
RFC 822 header folding conventions; no PEM-specific conventions are
defined for encapsulated header folding. The example shown in
Figure 4 shows (in its "MIC-Info:" field) an asymmetrically
encrypted quantity in its printably encoded representation,
illustrating the use of RFC 822 folding.
-----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,MIC-ONLY
Content-Domain: RFC822
Originator-Certificate:
MIIBlTCCAScCAWUwDQYJKoZIhvcNAQECBQAwUTELMAkGA1UEBhMCVVMxIDAeBgNV
BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDzAN
BgNVBAsTBk5PVEFSWTAeFw05MTA5MDQxODM4MTdaFw05MzA5MDMxODM4MTZaMEUx
CzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5jLjEU
MBIGA1UEAxMLVGVzdCBVc2VyIDEwWTAKBgRVCAEBAgICAANLADBIAkEAwHZHl7i+
yJcqDtjJCowzTdBJrdAiLAnSC+CnnjOJELyuQiBgkGrgIh3j8/x0fM+YrsyF1u3F
LZPVtzlndhYFJQIDAQABMA0GCSqGSIb3DQEBAgUAA1kACKr0PqphJYw1j+YPtcIq
iWlFPuN5jJ79Khfg7ASFxskYkEMjRNZV/HZDZQEhtVaU7Jxfzs2wfX5byMp2X3U/
5XUXGx7qusDgHQGs7Jk9W8CW1fuSWUgN4w==
Issuer-Certificate:
MIIB3DCCAUgCAQowDQYJKoZIhvcNAQECBQAwTzELMAkGA1UEBhMCVVMxIDAeBgNV
BAoTF1JTQSBEYXRhIFNlY3VyaXR5LCBJbmMuMQ8wDQYDVQQLEwZCZXRhIDExDTAL
BgNVBAsTBFRMQ0EwHhcNOTEwOTAxMDgwMDAwWhcNOTIwOTAxMDc1OTU5WjBRMQsw
CQYDVQQGEwJVUzEgMB4GA1UEChMXUlNBIERhdGEgU2VjdXJpdHksIEluYy4xDzAN
BgNVBAsTBkJldGEgMTEPMA0GA1UECxMGTk9UQVJZMHAwCgYEVQgBAQICArwDYgAw
XwJYCsnp6lQCxYykNlODwutF/jMJ3kL+3PjYyHOwk+/9rLg6X65B/LD4bJHtO5XW
cqAz/7R7XhjYCm0PcqbdzoACZtIlETrKrcJiDYoP+DkZ8k1gCk7hQHpbIwIDAQAB
MA0GCSqGSIb3DQEBAgUAA38AAICPv4f9Gx/tY4+p+4DB7MV+tKZnvBoy8zgoMGOx
dD2jMZ/3HsyWKWgSF0eH/AJB3qr9zosG47pyMnTf3aSy2nBO7CMxpUWRBcXUpE+x
EREZd9++32ofGBIXaialnOgVUn0OzSYgugiQ077nJLDUj0hQehCizEs5wUJ35a5h
MIC-Info: RSA-MD5,RSA,
jV2OfH+nnXHU8bnL8kPAad/mSQlTDZlbVuxvZAOVRZ5q5+Ejl5bQvqNeqOUNQjr6
EtE7K2QDeVMCyXsdJlA8fA==
LSBBIG1lc3NhZ2UgZm9yIHVzZSBpbiB0ZXN0aW5nLg0KLSBGb2xsb3dpbmcgaXMg
YSBibGFuayBsaW5lOg0KDQpUaGlzIGlzIHRoZSBlbmQuDQo=
-----END PRIVACY-ENHANCED MESSAGE-----
Example Encapsulated MIC-ONLY Message (Asymmetric Case)
Figure 4
4.6.1 Per-Message Encapsulated Header Fields
This group of encapsulated header fields contains fields which occur
no more than once in a PEM message, generally preceding all other
encapsulated header fields.
Dusse, Thompson Expires: September 1994 [Page 20]
Internet-Draft PEM Message Procedures March 1994
4.6.1.1 Proc-Type Field
The "Proc-Type:" encapsulated header field, required for all PEM
messages, identifies the type of processing performed on the
transmitted message. Only one "Proc-Type:" field occurs in a
message; the "Proc-Type:" field must be the first encapsulated
header field in the message.
The "Proc-Type:" field has two subfields, separated by a comma. The
first subfield is a decimal number which is used to distinguish
among incompatible encapsulated header field interpretations which
may arise as changes are made to this standard. Messages processed
according to this document will carry the subfield value "4" to
distinguish them from messages processed in accordance with prior
PEM RFCs. The second subfield assumes one of a set of string
values, defined in the following subsections.
4.6.1.1.1 ENCRYPTED
The "ENCRYPTED" specifier signifies that confidentiality,
authentication, integrity, and (given use of asymmetric key
management) non-repudiation of origin security services have been
applied to a PEM message's encapsulated text. ENCRYPTED messages
require a "DEK-Info:" field and individual recipient identifier and
"Key-Info:" fields for all message recipients.
4.6.1.1.2 MIC-ONLY
The "MIC-ONLY" specifier signifies that all of the security services
specified for ENCRYPTED messages, with the exception of
confidentiality, have been applied to a PEM message's encapsulated
text. MIC-ONLY messages are encoded (per Section 4.3.2.4 of this
document) to protect their encapsulated text against modifications
at message transfer or relay points.
Specification of MIC-ONLY, when applied in conjunction with certain
combinations of key management and MIC algorithm options, permits
certain fields which are superfluous in the absence of encryption to
be omitted from the encapsulated header. In particular, when a
keyless MIC computation is employed for recipients for whom
asymmetric cryptography is used, recipient identifier and "Key-
Info:" fields can be omitted. The "DEK-Info:" field can be omitted
for all "MIC-ONLY" messages.
4.6.1.1.3 MIC-CLEAR
The "MIC-CLEAR" specifier represents a PEM message with the same
security service selection as for a MIC-ONLY message. The set of
Dusse, Thompson Expires: September 1994 [Page 21]
Internet-Draft PEM Message Procedures March 1994
encapsulated header fields required in a MIC-CLEAR message is the
same as that required for a MIC-ONLY message.
MIC-CLEAR message processing omits the encoding step defined in
Section 4.3.2.4 of this document to protect a message's encapsulated
text against modifications within the MTS. As a result, a MIC-CLEAR
message's text can be read by recipients lacking access to PEM
software, even though such recipients cannot validate the message's
signature. The canonical encoding discussed in Section 4.3.2.2 is
performed, so interoperation among sites with different native
character sets and line representations is not precluded so long as
those native formats are unambiguously translatable to and from the
canonical form. (Such interoperability is feasible only for those
characters which are included in the canonical representation set.)
Omission of the printable encoding step implies that MIC-CLEAR
message MICs will be validatable only in environments where the MTS
does not modify messages in transit, or where the modifications
performed can be determined and inverted before MIC validation
processing. Failed MIC validation on a MIC-CLEAR message does not,
therefore, necessarily signify a security-relevant event; as a
result, it is recommended that PEM implementations reflect to their
users (in a suitable local fashion) the type of PEM message being
processed when reporting a MIC validation failure.
A case of particular relevance arises for inbound SMTP processing on
systems which delimit text lines with local native representations
other than the SMTP-conventional <CR><LF>. When mail is delivered
to a UA on such a system and presented for PEM processing, the
<CR><LF> has already been translated to local form. In order to
validate a MIC-CLEAR message's MIC in this situation, the PEM module
must recanonicalize the incoming message in order to determine the
inter-SMTP representation of the canonically encoded message (as
defined in Section 4.3.2.2 of this document), and must compute the
reference MIC based on that representation.
4.6.1.1.4 CRL
The "CRL" specifier indicates a special PEM message type, used to
transfer one or more Certificate Revocation Lists and certificates.
The format of PEM CRLs is defined in RFC 1422. No user data or
encapsulated text accompanies an encapsulated header specifying the
CRL message type; a correctly-formed CRL message's PEM header is
immediately followed by its terminating message boundary line, with
no blank line intervening.
Only three types of fields are valid in the encapsulated header
comprising a CRL message. The "CRL:" field carries a printable
representation of a CRL, encoded using the procedures defined in
Section 4.3.2.4 of this document. "CRL:" fields may (as an option)
be followed by no more than one "Originator-Certificate:" field and
Dusse, Thompson Expires: September 1994 [Page 22]
Internet-Draft PEM Message Procedures March 1994
any number of "Issuer-Certificate:" fields. The "Originator-
Certificate:" and "Issuer-Certificate:" fields refer to the most
recently previous "CRL:" field, and provide certificates useful in
validating the signature included in the CRL. "Originator-
Certificate:" and "Issuer-Certificate:" fields' contents are the
same for CRL messages as they are for other PEM message types.
4.6.1.2 Content-Domain Field
The "Content-Domain:" encapsulated header field describes the type
of content which is represented within a PEM message's encapsulated
text. It carries one string argument, whose value is defined as
"RFC822" to indicate processing of RFC-822 mail as defined in this
specification. It is anticipated that additional "Content-Domain:"
values will be defined subsequently, in additional or successor
documents to this specification. Only one "Content-Domain:" field
occurs in a PEM message; this field is the PEM message's second
encapsulated header field, immediately following the "Proc-Type:"
field.
4.6.1.3 DEK-Info Field
The "DEK-Info:" encapsulated header field identifies the message
text encryption algorithm and mode, and also carries any
cryptographic parameters (e.g., IVs) used for message encryption.
No more than one "DEK-Info:" field occurs in a message; the field is
required for all messages specified as "ENCRYPTED" in the "Proc-
Type:" field.
The "DEK-Info:" field carries either one argument or two arguments
separated by a comma. The first argument identifies the algorithm
and mode used for message text encryption. The second argument, if
present, carries any cryptographic parameters required by the
algorithm and mode identified in the first argument. Appropriate
message encryption algorithms, modes and identifiers and
corresponding cryptographic parameters and formats are defined in
RFC 1423.
4.6.2 Encapsulated Header Fields Normally Per-Message
This group of encapsulated header fields contains fields which
ordinarily occur no more than once per message. Depending on the
key management option(s) employed, some of these fields may be
absent from some messages.
Dusse, Thompson Expires: September 1994 [Page 23]
Internet-Draft PEM Message Procedures March 1994
4.6.2.1 Originator Identifier Fields
Originator identifier encapsulated header fields identify a
message's originator and provide the originator's IK identification
component. Two varieties of originator identifier fields are
defined,for symmetric and asymmetric key management. An
"Originator-ID-Symmetric:" header field is required for all PEM
messages employing symmetric key management. The "Originator-
Certificate:" field is used for asymmetric key management.
Most commonly, only one originator identifier field will occur
within a message. For the symmetric case, the IK identification
component carried in an "Originator-ID-Symmetric:" field applies to
processing of all subsequent "Recipient-ID-Symmetric:" fields until
another "Originator-ID-Symmetric:" field occurs. It is illegal for
a "Recipient-ID-Symmetric:" field to occur before a corresponding
"Originator-ID-Symmetric:" field has been provided. For the
asymmetric case, processing of recipient identifier fields is
logically independent of preceding originator identifier fields.
Multiple originator identifier fields may occur in a message when
different originator-oriented IK components must be used by a
message's originator in order to prepare a message so as to be
suitable for processing by different recipients. In particular,
multiple such fields will occur when both symmetric and asymmetric
cryptography are applied to a single message in order to process the
message for different recipients.
Originator-ID subfields are delimited by the comma character (","),
optionally followed by whitespace. Section 5.2, Interchange Keys,
discusses the semantics of these subfields and specifies the
alphabet from which they are chosen.
4.6.2.1.1 Originator-ID-Asymmetric Field
The "Originator-ID-Asymmetric:" field is supported to simplify
transition and interoperability with earlier implementations. The
"Originator-ID-Asymmetric:" field should be accepted in incoming
messages if possible but not included in outgoing messages [9]. The
"Originator-ID-Asymmetric:" field contains an Issuing Authority
subfield, and then a Version/Expiration subfield. This field is
used only when the information it carries is not available from an
included "Originator-Certificate:" field.
4.6.2.1.2 Originator-ID-Symmetric Field
The "Originator-ID-Symmetric:" field contains an Entity Identifier
subfield, followed by an (optional) Issuing Authority subfield, and
then an (optional) Version/Expiration subfield. Optional
"Originator-ID-Symmetric:" subfields may be omitted only if rendered
Dusse, Thompson Expires: September 1994 [Page 24]
Internet-Draft PEM Message Procedures March 1994
redundant by information carried in subsequent "Recipient-ID-
Symmetric:" fields, and will normally be omitted in such cases.
4.6.2.2 Originator-Certificate Field
The "Originator-Certificate:" encapsulated header field is used only
when asymmetric key management is employed for one or more of a
message's recipients. To facilitate processing by recipients (at
least in advance of general directory server availability),
inclusion of this field in all messages isrequired. The field
transfers an originator's certificate as a numeric quantity,
comprised of the certificate's DER encoding, represented in the
header field with the encoding mechanism defined in Section 4.3.2.4
of this document. The semantics of a certificate are discussed in
RFC 1422.
Note that the originator's certificate may be a self-signed
certificate, as described in RFC 1424 [10]. This provides sufficient
information for a recipient to determine if the originator's public
component has been certified by some issuer which the recipient
trusts.
4.6.2.3 MIC-Info Field
The "MIC-Info:" encapsulated header field, used only when asymmetric
key management is employed for at least one recipient of a message,
carries three arguments, separated by commas. The first argument
identifies the algorithm under which the accompanying MIC is
computed. The second argument identifies the algorithm under which
the accompanying MIC is signed. The third argument represents a MIC
signed with an originator's private key.
For the case of ENCRYPTED PEM messages, the signed MIC is, in turn,
symmetrically encrypted using the same DEK, algorithm, mode and
cryptographic parameters as are used to encrypt the message's
encapsulated text. This measure prevents unauthorized recipients
from determining whether an intercepted message corresponds to a
predetermined plaintext value.
Appropriate MIC algorithms and identifiers, signature algorithms and
identifiers, and signed MIC formats are defined in RFC 1423.
A "MIC-Info:" field will occur after a sequence of fields beginning
with an "Originator-ID-Asymmetric:" or "Originator-Certificate:"
field and followed by any associated "Issuer-Certificate:" fields.
A "MIC-Info:" field applies to all subsequent recipients for whom
asymmetric key management is used, until and unless overridden by a
subsequent "Originator-ID-Asymmetric:" or "Originator-Certificate:"
and corresponding "MIC-Info:".
Dusse, Thompson Expires: September 1994 [Page 25]
Internet-Draft PEM Message Procedures March 1994
4.6.3 Encapsulated Header Fields with Variable Occurrences
This group of encapsulated header fields contains fields which will
normally occur variable numbers of times within a message, with
numbers of occurrences ranging from zero to non-zero values which
are independent of the number of recipients.
4.6.3.1 Issuer-Certificate Field
The "Issuer-Certificate:" encapsulated header field is meaningful
only when asymmetric key management is used for at least one of a
message's recipients. A typical "Issuer-Certificate:" field would
contain the certificate containing the public component used to sign
the certificate carried in the message's "Originator-Certificate:"
field, for recipients' use in chaining through that certificate's
certification path. Other "Issuer-Certificate:" fields, typically
representing higher points in a certification path, also may be
included by an originator. It is recommended that the "Issuer-
Certificate:" fields be included in an order corresponding to
successive points in a certification path leading from the
originator to a common point shared with the message's recipients
(i.e., the Internet Certification Authority (ICA), unless a lower
Policy Certification Authority (PCA) or CA is common to all
recipients.) More information on certification paths can be found in
RFC 1422.
The certificate is represented in the same manner as defined for the
"Originator-Certificate:" field (transporting an encoded
representation of the certificate in X.509 [7] DER form), and any
"Issuer-Certificate:" fields will ordinarily follow the "Originator-
Certificate:" field directly. Use of the "Issuer-Certificate:"
field is optional even when asymmetric key management is employed,
although its incorporation is strongly recommended in the absence of
alternate directory server facilities from which recipients can
access issuers' certificates.
4.6.4 Per-Recipient Encapsulated Header Fields
The encapsulated header fields in this group appear for each of an
"ENCRYPTED" message's named recipients. For "MIC-ONLY" and "MIC-
CLEAR" messages, these fields are omitted for recipients for whom
asymmetric key management is employed in conjunction with a keyless
MIC algorithm but the fields appear for recipients for whom
symmetric key management or a keyed MIC algorithm is employed.
4.6.4.1 Recipient Identifier Fields
A recipient identifier encapsulated header field identifies a
recipient and provides the recipient's IK identification component.
Dusse, Thompson Expires: September 1994 [Page 26]
Internet-Draft PEM Message Procedures March 1994
One or more recipient identifier fields is included for each of a
message's intended recipients. Section 5.2, Interchange Keys,
discusses the semantics of the subfields and specifies the alphabet
from which they are chosen. Recipient identifier subfields are
delimited by the comma character (","), optionally followed by
whitespace.
For the symmetric case, all "Recipient-ID-Symmetric:" fields are
interpreted in the context of the most recent preceding "Originator-
ID-Symmetric:" field. It is illegal for a "Recipient-ID-Symmetric:"
field to occur in a header before the occurrence of a corresponding
"Originator-ID-Symmetric:" field.
For the asymmetric case, "Recipient-ID-Asymmetric:" and "Recipient-
Key-Asymmetric:" fields are logically independent of a message's
"Originator-ID-Asymmetric:" and "Originator-Certificate:" fields.
"Recipient-ID-Asymmetric:" and "Recipient-Key-Asymmetric:" fields,
and their associated "Key-Info:" fields, are included following a
header's originator-oriented fields. A "Key-Info:" field
corresponds to the preceding "Recipient-ID-Asymmetric:" or
"Recipient-Key-Asymmetric:" field. Use of the "Recipient-Key-
Asymmetric:" field to identify intended recipients in outgoing
messages is strongly recommended. The "Recipient-ID-Asymmetric:"
field should only be used to identify intended recipients when
preparing messages for earlier implementations.
4.6.4.1.1 Recipient-ID-Asymmetric Field
The "Recipient-ID-Asymmetric:" field is supported to simplify
transition and interoperability with earlier implementations [11].
The "Recipient-ID-Asymmetric:" field contains, in order, an Issuing
Authority subfield and a Version/Expiration subfield.
4.6.4.1.2 Recipient-Key-Asymmetric Field
The "Recipient-Key-Asymmetric:" field contains the recipient's
public component as a numeric quantity, comprised of the DER
encoding of a SubjectPublicKeyInfo, represented in the header field
with the encoding mechanism defined in Section 4.3.2.4 of this
document. The semantics of a SubjectPublicKeyInfo are discussed in
RFC 1422.
4.6.4.1.3 Recipient-ID-Symmetric Field
The "Recipient-ID-Symmetric:" field contains, in order, an Entity
Identifier subfield, an (optional) Issuing Authority subfield, and
an (optional) Version/Expiration subfield.
Dusse, Thompson Expires: September 1994 [Page 27]
Internet-Draft PEM Message Procedures March 1994
4.6.4.2 Key-Info Field
One "Key-Info:" field is included for each of a message's identified
recipients. In addition, it is recommended that PEM implementations
support (as a locally-selectable option) the ability to include a
"Key-Info:" field corresponding to a PEM message's originator,
following an originator identifier field and before any associated
recipient identifier fields, but inclusion of such a field is not a
requirement for conformance with this document.
Each "Key-Info:" field is interpreted in the context of the most
recent preceding originator or recipient identifier field; normally,
a "Key-Info:" field will immediately follow its associated
predecessor field. The "Key-Info:" field's argument(s) differ
depending on whether symmetric or asymmetric key management is used
for a particular recipient.
4.6.4.2.1 Symmetric Key Management
When symmetric key management is employed for a given recipient, the
"Key-Info:" encapsulated header field transfers four items,
separated by commas: an IK Use Indicator, a MIC Algorithm Indicator,
a DEK and a MIC. The IK Use Indicator identifies the algorithm and
mode in which the identified IK was used for DEK and MIC encryption
for a particular recipient. The MIC Algorithm Indicator identifies
the MIC computation algorithm used for a particular recipient. The
DEK and MIC are symmetrically encrypted under the IK identified by a
preceding "Recipient-ID-Symmetric:" field and/or prior "Originator-
ID-Symmetric:" field.
Appropriate symmetric encryption algorithms, modes and identifiers,
MIC computation algorithms and identifiers, and encrypted DEK and
MIC formats are defined in RFC 1423.
4.6.4.2.2 Asymmetric Key Management
When asymmetric key management is employed for a given recipient,
the "Key-Info:" field transfers two quantities, separated by a
comma. The first argument is an IK Use Indicator identifying the
algorithm and mode in which the DEK is asymmetrically encrypted.
The second argument is a DEK, asymmetrically encrypted under the
recipient's public component.
Appropriate asymmetric encryption algorithms and identifiers, and
encrypted DEK formats are defined in RFC 1423.
Dusse, Thompson Expires: September 1994 [Page 28]
Internet-Draft PEM Message Procedures March 1994
5. Key Management
Several cryptographic constructs are involved in supporting the PEM
message processing procedure. A set of fundamental elements is
assumed. Data Encrypting Keys (DEKs) are used to encrypt message
text and (for some MIC computation algorithms) in the message
integrity check (MIC) computation process. Interchange Keys (IKs)
are used to encrypt DEKs and MICs for transmission with messages.
In a certificate-based asymmetric key management architecture,
certificates are used as a means to provide entities' public
components and other information in a fashion which is securely
bound by a central authority. The remainder of this section
provides more information about these constructs.
5.1 Data Encrypting Keys (DEKs)
Data Encrypting Keys (DEKs) are used for encryption of message text
and (with some MIC computation algorithms) for computation of
message integrity check quantities (MICs). In the asymmetric key
management case, they are also used for encrypting signed MICs in
ENCRYPTED PEM messages. It is strongly recommended that DEKs be
generated and used on a one-time, per-message, basis. A transmitted
message will incorporate a representation of the DEK encrypted under
an appropriate interchange key (IK) for each of the named
recipients.
DEK generation can be performed either centrally by key distribution
centers (KDCs) or by endpoint systems. Dedicated KDC systems may
be able to implement stronger algorithms for random DEK generation
than can be supported in endpoint systems. On the other hand,
decentralization allows endpoints to be relatively self-sufficient,
reducing the level of trust which must be placed in components other
than those of a message's originator and recipient. Moreover,
decentralized DEK generation at endpoints reduces the frequency with
which originators must make real-time queries of (potentially
unique) servers in order to send mail, enhancing communications
availability.
When symmetric key management is used, one advantage of centralized
KDC-based generation is that DEKs can be returned to endpoints
already encrypted under the IKs of message recipients rather than
providing the IKs to the originators. This reduces IK exposure and
simplifies endpoint key management requirements. This approach has
less value if asymmetric cryptography is used for key management,
since per-recipient public IK components are assumed to be generally
available and per-originator private IK components need not
necessarily be shared with a KDC.
Dusse, Thompson Expires: September 1994 [Page 29]
Internet-Draft PEM Message Procedures March 1994
5.2 Interchange Keys (IKs)
Interchange Key (IK) components are used to encrypt DEKs and MICs.
In general, IK granularity is at the pairwise per-user level except
for mail sent to address lists comprising multiple users. In order
for two principals to engage in a useful exchange of PEM using
conventional cryptography, they must first possess common IK
components (when symmetric key management is used) or complementary
IK components (when asymmetric key management is used). When
symmetric cryptography is used, the IK consists of a single
component, used to encrypt both DEKs and MICs. When asymmetric
cryptography is used, a recipient's public component is used as an
IK to encrypt DEKs (a transformation invertible only by a recipient
possessing the corresponding private component), and the
originator's private component is used to encrypt MICs (a
transformation invertible by all recipients, since the originator's
certificate provides all recipients with the public component
required to perform MIC validation.
This document does not prescribe the means by which interchange keys
are made available to appropriate parties; such means may be
centralized (e.g., via key management servers) or decentralized
(e.g., via pairwise agreement and direct distribution among users).
In any case, any given IK component is associated with a responsible
Issuing Authority (IA). When certificate-based asymmetric key
management, as discussed in RFC 1422, is employed, the IA function
is performed by a Certification Authority (CA).
When an IA generates and distributes an IK component, associated
control information is provided to direct how it is to be used. In
order to select the appropriate IK(s) to use in message encryption,
an originator must retain a correspondence between IK components and
the recipients with which they are associated. Expiration date
information must also be retained, in order that cached entries may
be invalidated and replaced as appropriate.
Since a message may be sent with multiple IK components identified,
corresponding to multiple intended recipients, each recipient's UA
must be able to determine that recipient's intended IK component.
Moreover, if no corresponding IK component is available in the
recipient's database when a message arrives, the recipient must be
able to identify the required IK component and identify that IK
component's associated IA. Note that different IKs may be used for
different messages between a pair of communicants. Consider, for
example, one message sent from A to B and another message sent
(using the IK-per-list method) from A to a mailing list of which B
is a member. The first message would use IK components associated
individually with A and B, but the second would use an IK component
shared among list members.
When a PEM message is transmitted, an indication of the IK
components used for DEK and MIC encryption must be included. To
Dusse, Thompson Expires: September 1994 [Page 30]
Internet-Draft PEM Message Procedures March 1994
this end, originator and recipient identifier encapsulated header
fields provide (some or all of) the following data:
1. Identification of the relevant Issuing Authority (IA
subfield)
2. Identification of an entity with which a particular IK
component is associated (Entity Identifier or EI
subfield)
3. Version/Expiration subfield
In the asymmetric case, all necessary information associated with an
originator can be acquired by processing the certificate carried in
an "Originator-Certificate:" field.
The comma character (",") is used to delimit the subfields within an
Originator-ID or Recipient-ID. The IA, EI, and version/expiration
subfields are generated from a restricted character set, as
prescribed by the following BNF (using notation as defined in RFC
822, Sections 2 and 3.3):
IKsubfld := 1*ia-char
ia-char := DIGIT / ALPHA / "'" / "+" / "(" / ")" /
"." / "/" / "=" / "?" / "-" / "@" /
"%" / "!" / '"' / "_" / "<" / ">"
An example Recipient-ID field for the symmetric case is as follows:
Recipient-ID-Symmetric:
linn(_at_)zendia(_dot_)enet(_dot_)dec(_dot_)com,ptf-kmc,2
This example field indicates that IA "ptf-kmc" has issued an IK
component for use on messages sent to
"linn(_at_)zendia(_dot_)enet(_dot_)dec(_dot_)com",
and that the IA has provided the number 2 as a version indicator for
that IK component.
An example Recipient-ID field for the asymmetric case is as follows:
Recipient-ID-Asymmetric:
MFExCzAJBgNVBAYTAlVTMSAwHgYDVQQKExdSU0EgRGF0YSBTZWN1cml0eSwgSW5j
LjEPMA0GA1UECxMGQmV0YSAxMQ8wDQYDVQQLEwZOT1RBUlk=,66
This example field includes the printably encoded BER representation
of a certificate's issuer distinguished name, along with the
certificate serial number 66 as assigned by that issuer.
An example Recipient-Key-Asymmetric field for the asymmetric case is
as follows:
Recipient-Key-Asymmetric:
MHAwCgYEVQgBAQICArwDYgAwXwJYDNi3BbCOZY0FCRmtHi9l6dZhDpTnfBTBstEn
Dusse, Thompson Expires: September 1994 [Page 31]
Internet-Draft PEM Message Procedures March 1994
KI1/9QCugnBm+c1LsbTxy7v9566/JJ7n2AQbtO9XgDoE3CA7RWdW/KKdC+bq4Gs6
yTTBw1HDrJJcnBarGQIDAQAB
This example field includes the printably encoded DER representation
of a recipient's public component.
5.2.1 Subfield Definitions
The following subsections define the subfields of Originator-ID and
Recipient-ID fields.
5.2.1.1 Entity Identifier Subfield
An entity identifier (used only for "Originator-ID-Symmetric:" and
"Recipient-ID-Symmetric:" fields) is constructed as an IKsubfld.
More restrictively, an entity identifier subfield assumes the
following form:
<user>@<domain-qualified-host>
In order to support universal interoperability, it is necessary to
assume a universal form for the naming information. For the case of
installations which transform local host names before transmission
into the broader Internet, it is strongly recommended that the host
name as presented to the Internet be employed.
5.2.1.2 Issuing Authority Subfield
An IA identifier subfield is constructed as an IKsubfld. This
document does not define this subfield's contents for the symmetric
key management case. Any prospective IAs which are to issue
symmetric keys for use in conjunction with this document must
coordinate assignment of IA identifiers in a manner (centralized or
hierarchic) which assures uniqueness.
For the asymmetric key management case, the IA identifier subfield
will be formed from the ASN.1 BER representation of the
distinguished name of the issuing organization or organizational
unit. The distinguished encoding rules specified in Clause 8.7 of
Recommendation X.509 ("X.509 DER") are to be employed in generating
this representation. The encoded binary result will be represented
for inclusion in a transmitted header using the procedure defined in
Section 4.3.2.4 of this document.
5.2.1.3 Version/Expiration Subfield
A version/expiration subfield is constructed as an IKsubfld. For
the symmetric key management case, the version/expiration subfield
Dusse, Thompson Expires: September 1994 [Page 32]
Internet-Draft PEM Message Procedures March 1994
format is permitted to vary among different IAs, but must satisfy
certain functional constraints. An IA's version/expiration
subfields must be sufficient to distinguish among the set of IK
components issued by that IA for a given identified entity. Use of
a monotonically increasing number is sufficient to distinguish among
the IK components provided for an entity by an IA; use of a
timestamp additionally allows an expiration time or date to be
prescribed for an IK component.
For the asymmetric key management case, the version/expiration
subfield's value is the hexadecimal serial number of the certificate
being used in conjunction with the originator or recipient specified
in the "Originator-ID-Asymmetric:" or "Recipient-ID-Asymmetric:"
field in which the subfield occurs.
5.2.2 IK Cryptoperiod Issues
An IK component's cryptoperiod is dictated in part by a tradeoff
between key management overhead and revocation responsiveness. It
would be undesirable to delete an IK component permanently before
receipt of a message encrypted using that IK component, as this
would render the message permanently undecipherable. Access to an
expired IK component would be needed, for example, to process mail
received by a user (or system) which had been inactive for an
extended period of time. In order to enable very old IK components
to be deleted, a message's recipient desiring encrypted local long
term storage should transform the DEK used for message text
encryption via re-encryption under a locally maintained IK, rather
than relying on IA maintenance of old IK components for indefinite
periods.
6. User Naming
Unique naming of electronic mail users, as is needed in order to
select corresponding keys correctly, is an important topic and one
which has received (and continues to receive) significant study.
For the symmetric case, IK components are identified in PEM headers
through use of mailbox specifiers in traditional Internet-wide form
("user(_at_)domain-qualified-host"). Successful operation in this mode
relies on users (or their PEM implementations) being able to
determine the universal-form names corresponding to PEM originators
and recipients. If a PEM implementation operates in an environment
where addresses in a local form differing from the universal form
are used, translations must be performed in order to map between the
universal form and that local representation.
The use of user identifiers unrelated to the hosts on which the
users' mailboxes reside offers generality and value. X.500
distinguished names, as employed in the certificates of the
recommended key management infrastructure defined in RFC 1422,
Dusse, Thompson Expires: September 1994 [Page 33]
Internet-Draft PEM Message Procedures March 1994
provide a basis for such user identification. As directory services
become more pervasive, they will offer originators a means to search
for desired recipients which is based on a broader set of attributes
than mailbox specifiers alone. Future work is anticipated in
integration with directory services, particularly the mechanisms and
naming schema of the Internet OSI directory pilot activity.
7. Example User Interface and Implementation
In order to place the mechanisms and approaches discussed in this
document into context, this section presents an overview of a
hypothetical prototype implementation. This implementation is a
standalone program which is invoked by a user, and lies above the
existing UA sublayer. In the UNIX system, and possibly in other
environments as well, such a program can be invoked as a "filter"
within an electronic mail UA or a text editor, simplifying the
sequence of operations which must be performed by the user. This
form of integration offers the advantage that the program can be
used in conjunction with a range of UA programs, rather than being
compatible only with a particular UA.
When a user wishes to apply privacy enhancements to an outgoing
message, the user prepares the message's text and invokes the
standalone program, which in turn generates output suitable for
transmission via the UA. When a user receives a PEM message, the UA
delivers the message in encrypted form, suitable for decryption and
associated processing by the standalone program.
In this prototype implementation, a cache of IK components is
maintained in a local file, with entries managed manually based on
information provided by originators and recipients. For the
asymmetric key management case, certificates are acquired for a
user's PEM correspondents; in advance and/or in addition to
retrieval of certificates from directories, they can be extracted
from the "Originator-Certificate:" fields of received PEM messages.
The IK/certificate cache is, effectively, a simple database indexed
by mailbox names. IK components are selected for transmitted
messages based on the originator's identity and on recipient names,
and corresponding originator and recipient identifier fields are
placed into the message's encapsulated header. When a message is
received, these fields are used as a basis for a lookup in the
database, yielding the appropriate IK component entries. DEKs and
cryptographic parameters (e.g., IVs) are generated dynamically
within the program.
Options and destination addresses are selected by command line
arguments to the standalone program. The function of specifying
destination addresses to the privacy enhancement program is
logically distinct from the function of specifying the corresponding
addresses to the UA for use by the MTS. This separation results
Dusse, Thompson Expires: September 1994 [Page 34]
Internet-Draft PEM Message Procedures March 1994
from the fact that, in many cases, the local form of an address as
specified to a UA differs from the Internet global form as used in
"Originator-ID-Symmetric:" and "Recipient-ID-Symmetric:" fields.
8. Minimum Essential Requirements
This section summarizes particular capabilities which an
implementation must provide for full conformance with this document.
RFC 1422 specifies asymmetric, certificate-based key management
procedures to support the message processing procedures defined in
this document; PEM implementation support for these key management
procedures is strongly encouraged. Implementations supporting these
procedures must also be equipped to display the names of originator
and recipient PEM users in the X.500 DN form as authenticated by the
procedures of RFC 1422.
The message processing procedures defined here can also be used with
symmetric key management techniques, though no RFCs analogous to RFC
1422 are currently available to provide correspondingly detailed
description of suitable symmetric key management procedures. A
complete PEM implementation must support at least one of these
asymmetric and/or symmetric key management modes.
A full implementation of PEM is expected to be able to send and
receive ENCRYPTED, MIC-ONLY, and MIC-CLEAR messages, and to receive
CRL messages. Some level of support for generating and processing
nested and annotated PEM messages (for forwarding purposes) is to be
provided, and an implementation should be able to reduce ENCRYPTED
messages to MIC-ONLY or MIC-CLEAR for forwarding. Fully-conformant
implementations must be able to emit Originator-Certificate and
Issuer-Certificate fields, and to include a Key-Info field
corresponding to the originator, but users or configurers of PEM
implementations may be allowed the option of deactivating those
features.
9. Descriptive Grammar
This section provides a grammar describing the construction of a PEM
message.
; PEM BNF representation, using RFC 822 notation.
; imports field meta-syntax (field, field-name, field-body,
; field-body-contents) from RFC-822, sec. 3.2
; imports DIGIT, ALPHA, CRLF, text from RFC-822
; Note: algorithm and mode specifiers are officially defined
; in RFC 1423
<pemmsg> ::= <preeb>
Dusse, Thompson Expires: September 1994 [Page 35]
Internet-Draft PEM Message Procedures March 1994
<pemhdr>
[CRLF <pemtext>] ; absent for CRL message
<posteb>
<preeb> ::= "-----BEGIN PRIVACY-ENHANCED MESSAGE-----" CRLF
<posteb> ::= "-----END PRIVACY-ENHANCED MESSAGE-----" CRLF / <preeb>
<pemtext> ::= <encbinbody> ; for ENCRYPTED or MIC-ONLY messages
/ *(<text> CRLF) ; for MIC-CLEAR
<pemhdr> ::= <normalhdr> / <crlhdr>
<normalhdr> ::= <proctype>
<contentdomain>
[<dekinfo>] ; needed if ENCRYPTED
(1*(<origflds> *<recipflds>)) ; symmetric case --
; recipflds included for all proc types
/ ((1*<origflds>) *(<recipflds>)) ; asymmetric case --
; recipflds included for ENCRYPTED proc type
<crlhdr> ::= <proctype>
1*(<crl> [<cert>] *(<issuercert>))
<asymmorig> ::= <origid-asymm> / <cert>
<origflds> ::= <asymmorig> [<keyinfo>] *(<issuercert>)
<micinfo> ; asymmetric
/ <origid-symm> [<keyinfo>] ; symmetric
<recipflds> ::= <recipid> <keyinfo>
; definitions for PEM header fields
<proctype> ::= "Proc-Type" ":" "4" "," <pemtypes> CRLF
<contentdomain> ::= "Content-Domain" ":" <contentdescrip> CRLF
<dekinfo> ::= "DEK-Info" ":" <dekalgid> [ "," <dekparameters> ] CRLF
<symmid> ::= <IKsubfld> "," [<IKsubfld>] "," [<IKsubfld>]
<asymmid> ::= <IKsubfld> "," <IKsubfld>
<origid-asymm> ::= "Originator-ID-Asymmetric" ":" <asymmid> CRLF
<origid-symm> ::= "Originator-ID-Symmetric" ":" <symmid> CRLF
<recipid> ::= (<recipid-asymm> / <recipkey-asymm>) / <recipid-symm>
<recipid-asymm> ::= "Recipient-ID-Asymmetric" ":" <asymmid> CRLF
<recipkey-asymm> ::= "Recipient-Key-Asymmetric" ":" <encbin> CRLF
<recipid-symm> ::= "Recipient-ID-Symmetric" ":" <symmid> CRLF
<cert> ::= "Originator-Certificate" ":" <encbin> CRLF
<issuercert> ::= "Issuer-Certificate" ":" <encbin> CRLF
<micinfo> ::= "MIC-Info" ":" <micalgid> "," <ikalgid> ","
<asymsignmic> CRLF
<keyinfo> ::= "Key-Info" ":" <ikalgid> "," <micalgid> ","
<symencdek> "," <symencmic> CRLF ; symmetric case
/ "Key-Info" ":" <ikalgid> "," <asymencdek>
CRLF ; asymmetric case
Dusse, Thompson Expires: September 1994 [Page 36]
Internet-Draft PEM Message Procedures March 1994
<crl> ::= "CRL" ":" <encbin> CRLF
<pemtypes> ::= "ENCRYPTED" / "MIC-ONLY" / "MIC-CLEAR" / "CRL"
<encbinchar> ::= ALPHA / DIGIT / "+" / "/" / "="
<encbingrp> ::= 4*4<encbinchar>
<encbin> ::= 1*<encbingrp>
<encbinbody> ::= *(16*16<encbingrp> CRLF) [1*16<encbingrp> CRLF]
<IKsubfld> ::= 1*<ia-char>
; Note: "," removed from <ia-char> set so that Orig-ID and Recip-ID
; fields can be delimited with commas (not colons) like all other
; fields
<ia-char> ::= DIGIT / ALPHA / "'" / "+" / "(" / ")" /
"." / "/" / "=" / "?" / "-" / "@" /
"%" / "!" / '"' / "_" / "<" / ">"
<hexchar> ::= DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
; no lower case
; This specification defines one value ("RFC822") for
; <contentdescrip>: other values may be defined in future in
; separate or successor documents
;
<contentdescrip> ::= "RFC822"
; The following items are defined in RFC 1423
; <dekalgid>
; <dekparameters>
; <micalgid>
; <ikalgid>
; <asymsignmic>
; <symencdek>
; <symencmic>
; <asymencdek>
NOTES:
[1] Key generation for MIC computation and message text
encryption may either be performed by the sending host or by
a centralized server. This document does not constrain this
design alternative. Section 5.1 identifies possible
advantages of a centralized server approach if symmetric key
management is employed.
[2] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821,
August 1982.
[3] This transformation should occur only at an SMTP endpoint,
not at an intervening relay, but may take place at a gateway
system linking the SMTP realm with other environments.
[4] Use of a canonicalization procedure similar to that of SMTP
was selected because its functions are widely used and
Dusse, Thompson Expires: September 1994 [Page 37]
Internet-Draft PEM Message Procedures March 1994
implemented within the Internet mail community, not for
purposes of SMTP interoperability with this intermediate
result.
[5] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages", STD 11, RFC 822, August 1982.
[6] Rose, M. T. and Stefferud, E. A., "Proposed Standard for
Message Encapsulation", RFC 934, January 1985.
[7] CCITT Recommendation X.509 (1988), "The Directory -
Authentication Framework".
[8] Throughout this document we have adopted the terms "private
component" and "public component" to refer to the quantities
which are, respectively, kept secret and made publicly
available in asymmetric cryptosystems. This convention is
adopted to avoid possible confusion arising from use of the
term "secret key" to refer to either the former quantity or
to a key in a symmetric cryptosystem.
[9] Since the Originator-ID-Asymmetric field identifies the
issuer and serial number of a certificate for the
originator's public component, not the principle which owns
it, an application will only be able to recover the public
component if it can access that certificate based on the
issuer name, as opposed to subject name.
[10] RFC 1424 places no constraints in the validity period or
serial number in a self-signed certificate. For a self-signed
certificate which is used as an originator identifier, it is
recommended that the validity range reflect the period for
which the subject expects the public component and name
information to be valid. No constraints are needed for the
serial number. RFC 1424 also discusses the cryptographic
utility of verifying the signature on a self-signed
certificate.
[11] Since the Recipient-ID-Asymmetric field identifies the
issuer and serial number of a certificate for a public
component, it may not always be possible for the recipient of
a message to recognize what an originator has supplied or for
the originator to supply what the recipient will recognize.
For example, the originator may obtain the recipient's public
component from a certificate which the recipient is not aware
of. Therefore, the recipient will not recognize that the
Recipient-ID-Asymmetric is intended for him or her. Also, the
recipient may only recognize a certificate from an issuer
which the originator is not aware of. However, the recipient,
as the owner of the public component, will always be able to
recognize the Recipient-Key-Asymmetric identifier field.
Dusse, Thompson Expires: September 1994 [Page 38]
Internet-Draft PEM Message Procedures March 1994
Patent Statement
This version of Privacy Enhanced Mail (PEM) relies on the use of
patented public key encryption technology for authentication and
encryption. The Internet Standards Process as defined in RFC 1310
requires a written statement from the Patent holder that a license
will be made available to applicants under reasonable terms and
conditions prior to approving a specification as a Proposed, Draft
or Internet Standard.
The Massachusetts Institute of Technology and the Board of Trustees
of the Leland Stanford Junior University have granted Public Key
Partners (PKP) exclusive sub-licensing rights to the following
patents issued in the United States, and all of their corresponding
foreign patents:
Cryptographic Apparatus and Method
("Diffie-Hellman")............................... No. 4,200,770
Public Key Cryptographic Apparatus
and Method ("Hellman-Merkle").................... No. 4,218,582
Cryptographic Communications System and
Method ("RSA")................................... No. 4,405,829
Exponential Cryptographic Apparatus
and Method ("Hellman-Pohlig").................... No. 4,424,414
These patents are stated by PKP to cover all known methods of
practicing the art of Public Key encryption, including the
variations collectively known as El Gamal.
Public Key Partners has provided written assurance to the Internet
Society that parties will be able to obtain, under reasonable,
nondiscriminatory terms, the right to use the technology covered by
these patents. This assurance is documented in RFC 1170 titled
"Public Key Standards and Licenses". A copy of the written
assurance dated April 20, 1990, may be obtained from the Internet
Assigned Number Authority (IANA).
The Internet Society, Internet Architecture Board, Internet
Engineering Steering Group and the Corporation for National Research
Initiatives take no position on the validity or scope of the patents
and patent applications, nor on the appropriateness of the terms of
the assurance. The Internet Society and other groups mentioned
above have not made any determination as to any other intellectual
property rights which may apply to the practice of this standard.
Any further consideration of these matters is the user's own
responsibility.
Dusse, Thompson Expires: September 1994 [Page 39]
Internet-Draft PEM Message Procedures March 1994
Security Considerations
This entire document is about security.
Authors' Addresses
Steve Dusse
Jeff Thompson
RSA Data Security, Inc.
100 Marine Parkway
Redwood City, CA 94065
Phone: (415) 595-8782
FAX: (415) 595-1873
EMail: dusse(_at_)rsa(_dot_)com (Steve Dusse)
EMail: jefft(_at_)rsa(_dot_)com (Jeff Thompson)
Dusse, Thompson Expires: September 1994 [Page 40]