draft-ietf-pem-msgproc-02.txt   rfc1421.txt 
Network Working Group John Linn (DEC) Network Working Group J. Linn
INTERNET-DRAFT 1113ID IAB IRTF PSRG, IETF PEM WG Request for Comments: 1421 IAB IRTF PSRG, IETF PEM WG
23 July 1992 Obsoletes: 1113 February 1993
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 Privacy Enhancement for Internet Electronic Mail:
documents of the Internet Engineering Task Force (IETF), its Areas, Part I: Message Encryption and Authentication Procedures
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 Status of this Memo
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."
Please check the I-D abstract listing contained in each Internet This RFC specifies an IAB standards track protocol for the Internet
Draft directory to learn the current status of this or any other community, and requests discussion and suggestions for improvements.
Internet Draft. Please refer to the current edition of the "IAB Official Protocol
Standards" for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
This draft document will be submitted to the RFC editor as a Acknowledgements
standards document, and is submitted as a proposed successor to
current RFC-1113. References within the text of this Internet-Draft
to this document as an RFC, or to related Internet-Drafts cited as
"RFC [1114+]", "RFC [1115+]", and "RFC [FORMS+]" are not intended to
carry any connotation about the progression of these Internet-Drafts
through the IAB standards-track review cycle. Distribution of this
memo is unlimited. This specification was initially developed within
the Internet Research Task Force's Privacy and Security Research
Group and subsequently refined based on discussion in the Privacy-
Enhanced Mail Working Group of the Internet Engineering Task Force.
Comments should be sent to <pem-dev@tis.com>.
ACKNOWLEDGMENT
This document is the outgrowth of a series of meetings of the Privacy This document is the outgrowth of a series of meetings of the Privacy
and Security Research Group (PSRG) of the IRTF and the PEM Working and Security Research Group (PSRG) of the IRTF and the PEM Working
Group of the IETF. I would like to thank the members of the PSRG and Group of the IETF. I would like to thank the members of the PSRG and
the IETF PEM WG, as well as all participants in discussions on the the IETF PEM WG, as well as all participants in discussions on the
"pem-dev@tis.com" mailing list, for their contributions to this "pem-dev@tis.com" mailing list, for their contributions to this
document. document.
1 Executive Summary 1. Executive Summary
This document defines message encryption and authentication This document defines message encryption and authentication
procedures, in order to provide privacy-enhanced mail (PEM) services procedures, in order to provide privacy-enhanced mail (PEM) services
for electronic mail transfer in the Internet. It is intended to for electronic mail transfer in the Internet. It is intended to
become one member of a related set of four RFCs. The procedures become one member of a related set of four RFCs. The procedures
defined in the current document are intended to be compatible with a defined in the current document are intended to be compatible with a
wide range of key management approaches, including both symmetric wide range of key management approaches, including both symmetric
(secret-key) and asymmetric (public-key) approaches for encryption of (secret-key) and asymmetric (public-key) approaches for encryption of
data encrypting keys. Use of symmetric cryptography for message text data encrypting keys. Use of symmetric cryptography for message text
encryption and/or integrity check computation is anticipated. RFC encryption and/or integrity check computation is anticipated. RFC
[1114+] specifies supporting key management mechanisms based on the 1422 specifies supporting key management mechanisms based on the use
use of public-key certificates. RFC [1115+] specifies algorithms, of public-key certificates. RFC 1423 specifies algorithms, modes,
modes, and associated identifiers relevant to the current RFC and to and associated identifiers relevant to the current RFC and to RFC
RFC [1114+]. RFC [FORMS+] provides details of paper and electronic 1422. RFC 1424 provides details of paper and electronic formats and
formats and procedures for the key management infrastructure being procedures for the key management infrastructure being established in
established in support of these services. support of these services.
Privacy enhancement services (confidentiality, authentication, Privacy enhancement services (confidentiality, authentication,
message integrity assurance, and non-repudiation of origin) are message integrity assurance, and non-repudiation of origin) are
offered through the use of end-to-end cryptography between originator offered through the use of end-to-end cryptography between originator
and recipient processes at or above the User Agent level. No special and recipient processes at or above the User Agent level. No special
processing requirements are imposed on the Message Transfer System at processing requirements are imposed on the Message Transfer System at
endpoints or at intermediate relay sites. This approach allows endpoints or at intermediate relay sites. This approach allows
privacy enhancement facilities to be incorporated selectively on a privacy enhancement facilities to be incorporated selectively on a
site-by-site or user-by-user basis without impact on other Internet site-by-site or user-by-user basis without impact on other Internet
entities. Interoperability among heterogeneous components and mail entities. Interoperability among heterogeneous components and mail
transport facilities is supported. transport facilities is supported.
The current specification's scope is confined to PEM processing The current specification's scope is confined to PEM processing
procedures for the RFC-822 textual mail environment, and defines the procedures for the RFC-822 textual mail environment, and defines the
Content-Domain indicator value "RFC822" to signify this usage. Content-Domain indicator value "RFC822" to signify this usage.
Follow-on work in integration of PEM capabilities with other Follow-on work in integration of PEM capabilities with other
messaging environments (e.g., MIME) is anticipated and will be messaging environments (e.g., MIME) is anticipated and will be
addressed in separate and/or successor documents, at which point addressed in separate and/or successor documents, at which point
additional Content-Domain indicator values will be defined. additional Content-Domain indicator values will be defined.
2 Terminology 2. Terminology
For descriptive purposes, this RFC uses some terms defined in the OSI For descriptive purposes, this RFC uses some terms defined in the OSI
X.400 Message Handling System Model per the CCITT Recommendations. X.400 Message Handling System Model per the CCITT Recommendations.
This section replicates a portion of (1984) X.400's Section 2.2.1, 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 "Description of the MHS Model: Overview" in order to make the
terminology clear to readers who may not be familiar with the OSI MHS terminology clear to readers who may not be familiar with the OSI MHS
Model. Model.
In the [MHS] model, a user is a person or a computer application. A 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) user is referred to as either an originator (when sending a message)
skipping to change at page 4, line 9 skipping to change at page 3, line 5
The MTS is composed of a number of Message Transfer Agents (MTAs). The MTS is composed of a number of Message Transfer Agents (MTAs).
Operating together, the MTAs relay messages and deliver them to the Operating together, the MTAs relay messages and deliver them to the
intended recipient UAs, which then make the messages available to the intended recipient UAs, which then make the messages available to the
intended recipients. intended recipients.
The collection of UAs and MTAs is called the Message Handling System 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 (MHS). The MHS and all of its users are collectively referred to as
the Message Handling Environment. the Message Handling Environment.
3 Services, Constraints, and Implications 3. Services, Constraints, and Implications
This RFC defines mechanisms to enhance privacy for electronic mail This RFC defines mechanisms to enhance privacy for electronic mail
transferred in the Internet. The facilities discussed in this RFC transferred in the Internet. The facilities discussed in this RFC
provide privacy enhancement services on an end-to-end basis between provide privacy enhancement services on an end-to-end basis between
originator and recipient processes residing at the UA level or above. originator and recipient processes residing at the UA level or above.
No privacy enhancements are offered for message fields which are No privacy enhancements are offered for message fields which are
added or transformed by intermediate relay points between PEM added or transformed by intermediate relay points between PEM
processing components. processing components.
If an originator elects to perform PEM processing on an outbound If an originator elects to perform PEM processing on an outbound
skipping to change at page 6, line 20 skipping to change at page 4, line 44
UA-integrated approach would allow. UA-integrated approach would allow.
6. The defined mechanisms support privacy protection of 6. The defined mechanisms support privacy protection of
electronic mail addressed to mailing lists (distribution electronic mail addressed to mailing lists (distribution
lists, in ISO parlance). lists, in ISO parlance).
7. The mechanisms defined within this RFC are compatible with a 7. The mechanisms defined within this RFC are compatible with a
variety of supporting key management approaches, including variety of supporting key management approaches, including
(but not limited to) manual pre-distribution, centralized (but not limited to) manual pre-distribution, centralized
key distribution based on symmetric cryptography, and the key distribution based on symmetric cryptography, and the
use of public-key certificates per RFC [1114+]. Different use of public-key certificates per RFC 1422. Different
key management mechanisms may be used for different key management mechanisms may be used for different
recipients of a multicast message. For two PEM recipients of a multicast message. For two PEM
implementations to interoperate, they must share a common implementations to interoperate, they must share a common
key management mechanism; support for the mechanism defined key management mechanism; support for the mechanism defined
in RFC [1114+] is strongly encouraged. in RFC 1422 is strongly encouraged.
In order to achieve applicability to the broadest possible range of In order to achieve applicability to the broadest possible range of
Internet hosts and mail systems, and to facilitate pilot Internet hosts and mail systems, and to facilitate pilot
implementation and testing without the need for prior and pervasive implementation and testing without the need for prior and pervasive
modifications throughout the Internet, the following design modifications throughout the Internet, the following design
principles were applied in selecting the set of features specified in principles were applied in selecting the set of features specified in
this RFC: this RFC:
1. This RFC's measures are restricted to implementation at 1. This RFC's measures are restricted to implementation at
endpoints and are amenable to integration with existing endpoints and are amenable to integration with existing
skipping to change at page 8, line 17 skipping to change at page 6, line 21
multiple users, multiple users,
6. assurance of message receipt and non-deniability of receipt, 6. assurance of message receipt and non-deniability of receipt,
7. automatic association of acknowledgments with the messages 7. automatic association of acknowledgments with the messages
to which they refer, and to which they refer, and
8. message duplicate detection, replay prevention, or other 8. message duplicate detection, replay prevention, or other
stream-oriented services stream-oriented services
4 Processing of Messages 4. Processing of Messages
4.1 Message Processing Overview 4.1 Message Processing Overview
This subsection provides a high-level overview of the components and This subsection provides a high-level overview of the components and
processing steps involved in electronic mail privacy enhancement processing steps involved in electronic mail privacy enhancement
processing. Subsequent subsections will define the procedures in processing. Subsequent subsections will define the procedures in
more detail. more detail.
4.1.1 Types of Keys 4.1.1 Types of Keys
skipping to change at page 13, line 15 skipping to change at page 9, line 49
4.1.2.2 Error Cases 4.1.2.2 Error Cases
A variety of error cases may occur and be detected in the course of 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 processing a received PEM message. The specific actions to be taken
in response to such conditions are local matters, varying as in response to such conditions are local matters, varying as
functions of user preferences and the type of user interface provided functions of user preferences and the type of user interface provided
by a particular PEM implementation, but certain general by a particular PEM implementation, but certain general
recommendations are appropriate. Syntactically invalid PEM messages recommendations are appropriate. Syntactically invalid PEM messages
should be flagged as such, preferably with collection of diagnostic should be flagged as such, preferably with collection of diagnostic
information to support debugging of incompatibilities or other information to support debugging of incompatibilities or other
failures. RFC [1114+] defines specific error processing requirements failures. RFC 1422 defines specific error processing requirements
relevant to the certificate-based key management mechanisms defined relevant to the certificate-based key management mechanisms defined
therein. therein.
Syntactically valid PEM messages which yield MIC failures raise Syntactically valid PEM messages which yield MIC failures raise
special concern, as they may result from attempted attacks or forged special concern, as they may result from attempted attacks or forged
messages. As such, it is unsuitable to display their contents to messages. As such, it is unsuitable to display their contents to
recipient users without first indicating the fact that the contents' recipient users without first indicating the fact that the contents'
authenticity and integrity cannot be guaranteed and then receiving authenticity and integrity cannot be guaranteed and then receiving
positive user confirmation of such a warning. MIC-CLEAR messages positive user confirmation of such a warning. MIC-CLEAR messages
(discussed in Section 4.6.1.1.3 of this RFC) raise special concerns, (discussed in Section 4.6.1.1.3 of this RFC) raise special concerns,
as MIC failures on such messages may occur for a broader range of as MIC failures on such messages may occur for a broader range of
benign causes than are applicable to other PEM message types. benign causes than are applicable to other PEM message types.
4.2 Encryption Algorithms, Modes, and Parameters 4.2 Encryption Algorithms, Modes, and Parameters
For use in conjunction with this RFC, RFC [1115+] defines the For use in conjunction with this RFC, RFC 1423 defines the
appropriate algorithms, modes, and associated identifiers to be used appropriate algorithms, modes, and associated identifiers to be used
for encryption of message text with DEKs. for encryption of message text with DEKs.
The mechanisms defined in this RFC incorporate facilities for The mechanisms defined in this RFC incorporate facilities for
transmission of cryptographic parameters (e.g., pseudorandom transmission of cryptographic parameters (e.g., pseudorandom
Initializing Vectors (IVs)) with PEM messages to which the Initializing Vectors (IVs)) with PEM messages to which the
confidentiality service is applied, when required by symmetric confidentiality service is applied, when required by symmetric
message encryption algorithms and modes specified in RFC [1115+]. message encryption algorithms and modes specified in RFC 1423.
Certain operations require encryption of DEKs, MICs, and digital Certain operations require encryption of DEKs, MICs, and digital
signatures under an IK for purposes of transmission. A header signatures under an IK for purposes of transmission. A header
facility indicates the mode in which the IK is used for encryption. facility indicates the mode in which the IK is used for encryption.
RFC [1115+] specifies encryption algorithm and mode identifiers and RFC 1423 specifies encryption algorithm and mode identifiers and
minimum essential support requirements for key encryption processing. minimum essential support requirements for key encryption processing.
RFC [1114+] specifies asymmetric, certificate-based key management RFC 1422 specifies asymmetric, certificate-based key management
procedures based on CCITT Recommendation X.509 to support the message procedures based on CCITT Recommendation X.509 to support the message
processing procedures defined in this document. Support for the key processing procedures defined in this document. Support for the key
management approach defined in RFC [1114+] is strongly recommended. management approach defined in RFC 1422 is strongly recommended. The
The message processing procedures can also be used with symmetric key message processing procedures can also be used with symmetric key
management, given prior distribution of suitable symmetric IKs, but management, given prior distribution of suitable symmetric IKs, but
no current RFCs specify key distribution procedures for such IKs. no current RFCs specify key distribution procedures for such IKs.
4.3 Privacy Enhancement Message Transformations 4.3 Privacy Enhancement Message Transformations
4.3.1 Constraints 4.3.1 Constraints
An electronic mail encryption mechanism must be compatible with the An electronic mail encryption mechanism must be compatible with the
transparency constraints of its underlying electronic mail transparency constraints of its underlying electronic mail
facilities. These constraints are generally established based on facilities. These constraints are generally established based on
skipping to change at page 15, line 13 skipping to change at page 11, line 24
2. Text lines, delimited by the character pair <CR><LF>, must 2. Text lines, delimited by the character pair <CR><LF>, must
be no more than 1000 characters long. be no more than 1000 characters long.
3. Since the string <CR><LF>.<CR><LF> indicates the end of a 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, it must not occur in text prior to the end of a
message. message.
Although SMTP specifies a standard representation for line delimiters Although SMTP specifies a standard representation for line delimiters
(ASCII <CR><LF>), numerous systems in the Internet use a different (ASCII <CR><LF>), numerous systems in the Internet use a different
native representation to delimit lines. For example, the <CR><LF> native representation to delimit lines. For example, the <CR><LF>
sequences delimiting lines in mail inbound to UNIX(tm) systems are sequences delimiting lines in mail inbound to UNIX systems are
transformed to single <LF>s as mail is written into local mailbox transformed to single <LF>s as mail is written into local mailbox
files. Lines in mail incoming to record-oriented systems (such as files. Lines in mail incoming to record-oriented systems (such as
VAX VMS) may be converted to appropriate records by the destination VAX VMS) may be converted to appropriate records by the destination
SMTP server [3]. As a result, if the encryption process generated SMTP server [3]. As a result, if the encryption process generated
<CR>s or <LF>s, those characters might not be accessible to a <CR>s or <LF>s, those characters might not be accessible to a
recipient UA program at a destination which uses different line recipient UA program at a destination which uses different line
delimiting conventions. It is also possible that conversion between delimiting conventions. It is also possible that conversion between
tabs and spaces may be performed in the course of mapping 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 inter-SMTP and local format; this is a matter of local option. If
such transformations changed the form of transmitted ciphertext, such transformations changed the form of transmitted ciphertext,
skipping to change at page 17, line 26 skipping to change at page 13, line 10
Authentication processing is applicable to PEM message types Authentication processing is applicable to PEM message types
ENCRYPTED, MIC-ONLY, and MIC-CLEAR. The canonical form is input to ENCRYPTED, MIC-ONLY, and MIC-CLEAR. The canonical form is input to
the selected MIC computation algorithm in order to compute an the selected MIC computation algorithm in order to compute an
integrity check quantity for the message. No padding is added to the integrity check quantity for the message. No padding is added to the
canonical form before submission to the MIC computation algorithm, canonical form before submission to the MIC computation algorithm,
although certain MIC algorithms will apply their own padding in the although certain MIC algorithms will apply their own padding in the
course of computing a MIC. course of computing a MIC.
Encryption processing is applicable only to PEM message type Encryption processing is applicable only to PEM message type
ENCRYPTED. RFC [1115+] defines the padding technique used to support ENCRYPTED. RFC 1423 defines the padding technique used to support
encryption of the canonically-encoded message text. encryption of the canonically-encoded message text.
4.3.2.4 Step 4: Printable Encoding 4.3.2.4 Step 4: Printable Encoding
This printable encoding step is applicable to PEM message types This printable encoding step is applicable to PEM message types
ENCRYPTED and MIC-ONLY. The same processing is also employed in ENCRYPTED and MIC-ONLY. The same processing is also employed in
representation of certain specifically identified PEM encapsulated representation of certain specifically identified PEM encapsulated
header field quantities as cited in Section 4.6. Proceeding from header field quantities as cited in Section 4.6. Proceeding from
left to right, the bit string resulting from step 3 is encoded into left to right, the bit string resulting from step 3 is encoded into
characters which are universally representable at all sites, though characters which are universally representable at all sites, though
skipping to change at page 23, line 12 skipping to change at page 17, line 47
be included within the encapsulated text portion in addition to its be included within the encapsulated text portion in addition to its
inclusion in the enclosing MTS header. For example, an originator inclusion in the enclosing MTS header. For example, an originator
wishing to provide recipients with a protected indication of a wishing to provide recipients with a protected indication of a
message's position in a series of messages could include within the message's position in a series of messages could include within the
encapsulated text a copy of a timestamp or message counter value encapsulated text a copy of a timestamp or message counter value
possessing end-to-end significance and extracted from an enclosing possessing end-to-end significance and extracted from an enclosing
MTS header field. (Note: mailbox specifiers as entered by end users MTS header field. (Note: mailbox specifiers as entered by end users
incorporate local conventions and are subject to modification at incorporate local conventions and are subject to modification at
intermediaries, so inclusion of such specifiers within encapsulated intermediaries, so inclusion of such specifiers within encapsulated
text should not be regarded as a suitable alternative to the text should not be regarded as a suitable alternative to the
authentication semantics defined in RFC [1114+] and based on X.500 authentication semantics defined in RFC 1422 and based on X.500
Distinguished Names.) The set of header information (if any) included Distinguished Names.) The set of header information (if any) included
within the encapsulated text of messages is a local matter, and this within the encapsulated text of messages is a local matter, and this
RFC does not specify formatting conventions to distinguish replicated RFC does not specify formatting conventions to distinguish replicated
header fields from other encapsulated text. header fields from other encapsulated text.
4.5 Mail for Mailing Lists 4.5 Mail for Mailing Lists
When mail is addressed to mailing lists, two different methods of When mail is addressed to mailing lists, two different methods of
processing can be applicable: the IK-per-list method and the IK-per- processing can be applicable: the IK-per-list method and the IK-per-
recipient method. Hybrid approaches are also possible, as in the recipient method. Hybrid approaches are also possible, as in the
skipping to change at page 25, line 11 skipping to change at page 19, line 25
messages. Figure 2 assumes the use of symmetric cryptography for key messages. Figure 2 assumes the use of symmetric cryptography for key
management. Figure 3 illustrates an example encapsulated ENCRYPTED management. Figure 3 illustrates an example encapsulated ENCRYPTED
message in which asymmetric key management is used. message in which asymmetric key management is used.
-----BEGIN PRIVACY-ENHANCED MESSAGE----- -----BEGIN PRIVACY-ENHANCED MESSAGE-----
Proc-Type: 4,ENCRYPTED Proc-Type: 4,ENCRYPTED
Content-Domain: RFC822 Content-Domain: RFC822
DEK-Info: DES-CBC,F8143EDE5960C597 DEK-Info: DES-CBC,F8143EDE5960C597
Originator-ID-Symmetric: linn@zendia.enet.dec.com,, Originator-ID-Symmetric: linn@zendia.enet.dec.com,,
Recipient-ID-Symmetric: linn@zendia.enet.dec.com,ptf-kmc,3 Recipient-ID-Symmetric: linn@zendia.enet.dec.com,ptf-kmc,3
Key-Info: DES-ECB,RSA-MD2,9FD3AAD2F2691B9A,B70665BB9BF7CBCDA60195DB94F727D3 Key-Info: DES-ECB,RSA-MD2,9FD3AAD2F2691B9A,
B70665BB9BF7CBCDA60195DB94F727D3
Recipient-ID-Symmetric: pem-dev@tis.com,ptf-kmc,4 Recipient-ID-Symmetric: pem-dev@tis.com,ptf-kmc,4
Key-Info: DES-ECB,RSA-MD2,161A3F75DC82EF26,E2EF532C65CBCFF79F83A2658132DB47 Key-Info: DES-ECB,RSA-MD2,161A3F75DC82EF26,
E2EF532C65CBCFF79F83A2658132DB47
LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M LLrHB0eJzyhP+/fSStdW8okeEnv47jxe7SJ/iN72ohNcUk2jHEUSoH1nvNSIWL9M
8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk 8tEjmF/zxB+bATMtPjCUWbz8Lr9wloXIkjHUlBLpvXR0UrUzYbkNpk0agV2IzUpk
J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot J6UiRRGcDSvzrsoK+oNvqu6z7Xs5Xfz5rDqUcMlK1Z6720dcBWGGsDLpTpSCnpot
dXd/H5LMDWnonNvPCwQUHt== dXd/H5LMDWnonNvPCwQUHt==
-----END PRIVACY-ENHANCED MESSAGE----- -----END PRIVACY-ENHANCED MESSAGE-----
Example Encapsulated Message (Symmetric Case) Example Encapsulated Message (Symmetric Case)
Figure 2 Figure 2
skipping to change at page 27, line 22 skipping to change at page 22, line 14
using asymmetric algorithms are large in size, use of a more space- using asymmetric algorithms are large in size, use of a more space-
efficient encoding technique is appropriate for such quantities, and efficient encoding technique is appropriate for such quantities, and
the encoding mechanism defined in Section 4.3.2.4 of this RFC, the encoding mechanism defined in Section 4.3.2.4 of this RFC,
representing 6 bits per printed character, is adopted for this representing 6 bits per printed character, is adopted for this
purpose. purpose.
Encapsulated headers of PEM messages are folded using whitespace per Encapsulated headers of PEM messages are folded using whitespace per
RFC 822 header folding conventions; no PEM-specific conventions are RFC 822 header folding conventions; no PEM-specific conventions are
defined for encapsulated header folding. The example shown in Figure defined for encapsulated header folding. The example shown in Figure
4 shows asymmetrically encrypted quantities (e.g., "MIC-Info:", 4 shows (in its "MIC-Info:" field) an asymmetrically encrypted
"Key-Info:") in their printably encoded representations, illustrating quantity in its printably encoded representation, illustrating the
the use of RFC 822 folding. use of RFC 822 folding.
In contrast to the encapsulated header representations defined in RFC In contrast to the encapsulated header representations defined in RFC
1113 and its precursors, the field identifiers adopted in this RFC do 1113 and its precursors, the field identifiers adopted in this RFC do
not begin with the prefix "X-" (for example, the field previously not begin with the prefix "X-" (for example, the field previously
denoted "X-Key-Info:" is now denoted "Key-Info:") and such prefixes denoted "X-Key-Info:" is now denoted "Key-Info:") and such prefixes
are not to be emitted by implementations conformant to this RFC. To are not to be emitted by implementations conformant to this RFC. To
simplify transition and interoperability with earlier simplify transition and interoperability with earlier
implementations, it is suggested that implementations based on this implementations, it is suggested that implementations based on this
RFC accept incoming encapsulated header fields carrying the "X-" RFC accept incoming encapsulated header fields carrying the "X-"
prefix and act on such fields as if the "X-" were not present. prefix and act on such fields as if the "X-" were not present.
skipping to change at page 31, line 29 skipping to change at page 25, line 38
MIC-CLEAR message's MIC in this situation, the PEM module must MIC-CLEAR message's MIC in this situation, the PEM module must
recanonicalize the incoming message in order to determine the inter- recanonicalize the incoming message in order to determine the inter-
SMTP representation of the canonically encoded message (as defined in SMTP representation of the canonically encoded message (as defined in
Section 4.3.2.2 of this RFC), and must compute the reference MIC Section 4.3.2.2 of this RFC), and must compute the reference MIC
based on that representation. based on that representation.
4.6.1.1.4 CRL 4.6.1.1.4 CRL
The "CRL" specifier indicates a special PEM message type, used to The "CRL" specifier indicates a special PEM message type, used to
transfer one or more Certificate Revocation Lists. The format of PEM transfer one or more Certificate Revocation Lists. The format of PEM
CRLs is defined in RFC [1114+]. No user data or encapsulated text CRLs is defined in RFC 1422. No user data or encapsulated text
accompanies an encapsulated header specifying the CRL message type; a accompanies an encapsulated header specifying the CRL message type; a
correctly-formed CRL message's PEM header is immediately followed by correctly-formed CRL message's PEM header is immediately followed by
its terminating message boundary line, with no blank line its terminating message boundary line, with no blank line
intervening. intervening.
Only three types of fields are valid in the encapsulated header Only three types of fields are valid in the encapsulated header
comprising a CRL message. The "CRL:" field carries a printable comprising a CRL message. The "CRL:" field carries a printable
representation of a CRL, encoded using the procedures defined in representation of a CRL, encoded using the procedures defined in
Section 4.3.2.4 of this RFC. "CRL:" fields may (as an option) be Section 4.3.2.4 of this RFC. "CRL:" fields may (as an option) be
followed by no more than one "Originator-Certificate:" field and any followed by no more than one "Originator-Certificate:" field and any
skipping to change at page 32, line 38 skipping to change at page 26, line 36
"DEK-Info:" field occurs in a message; the field is required for all "DEK-Info:" field occurs in a message; the field is required for all
messages specified as "ENCRYPTED" in the "Proc-Type:" field. messages specified as "ENCRYPTED" in the "Proc-Type:" field.
The "DEK-Info:" field carries either one argument or two arguments The "DEK-Info:" field carries either one argument or two arguments
separated by a comma. The first argument identifies the algorithm separated by a comma. The first argument identifies the algorithm
and mode used for message text encryption. The second argument, if and mode used for message text encryption. The second argument, if
present, carries any cryptographic parameters required by the present, carries any cryptographic parameters required by the
algorithm and mode identified in the first argument. Appropriate algorithm and mode identified in the first argument. Appropriate
message encryption algorithms, modes and identifiers and message encryption algorithms, modes and identifiers and
corresponding cryptographic parameters and formats are defined in RFC corresponding cryptographic parameters and formats are defined in RFC
[1115+]. 1423.
4.6.2 Encapsulated Header Fields Normally Per-Message 4.6.2 Encapsulated Header Fields Normally Per-Message
This group of encapsulated header fields contains fields which This group of encapsulated header fields contains fields which
ordinarily occur no more than once per message. Depending on the key ordinarily occur no more than once per message. Depending on the key
management option(s) employed, some of these fields may be absent management option(s) employed, some of these fields may be absent
from some messages. from some messages.
4.6.2.1 Originator-ID Fields 4.6.2.1 Originator-ID Fields
skipping to change at page 34, line 37 skipping to change at page 28, line 16
The "Originator-Certificate:" encapsulated header field is used only The "Originator-Certificate:" encapsulated header field is used only
when asymmetric key management is employed for one or more of a when asymmetric key management is employed for one or more of a
message's recipients. To facilitate processing by recipients (at message's recipients. To facilitate processing by recipients (at
least in advance of general directory server availability), inclusion least in advance of general directory server availability), inclusion
of this field in all messages is strongly recommended. The field of this field in all messages is strongly recommended. The field
transfers an originator's certificate as a numeric quantity, transfers an originator's certificate as a numeric quantity,
comprised of the certificate's DER encoding, represented in the comprised of the certificate's DER encoding, represented in the
header field with the encoding mechanism defined in Section 4.3.2.4 header field with the encoding mechanism defined in Section 4.3.2.4
of this RFC. The semantics of a certificate are discussed in RFC of this RFC. The semantics of a certificate are discussed in RFC
[1114+]. 1422.
4.6.2.3 MIC-Info Field 4.6.2.3 MIC-Info Field
The "MIC-Info:" encapsulated header field, used only when asymmetric The "MIC-Info:" encapsulated header field, used only when asymmetric
key management is employed for at least one recipient of a message, key management is employed for at least one recipient of a message,
carries three arguments, separated by commas. The first argument carries three arguments, separated by commas. The first argument
identifies the algorithm under which the accompanying MIC is identifies the algorithm under which the accompanying MIC is
computed. The second argument identifies the algorithm under which computed. The second argument identifies the algorithm under which
the accompanying MIC is signed. The third argument represents a MIC the accompanying MIC is signed. The third argument represents a MIC
signed with an originator's private key. signed with an originator's private key.
For the case of ENCRYPTED PEM messages, the signed MIC is, in turn, For the case of ENCRYPTED PEM messages, the signed MIC is, in turn,
symmetrically encrypted using the same DEK, algorithm, mode and symmetrically encrypted using the same DEK, algorithm, mode and
cryptographic parameters as are used to encrypt the message's cryptographic parameters as are used to encrypt the message's
encapsulated text. This measure prevents unauthorized recipients encapsulated text. This measure prevents unauthorized recipients
from determining whether an intercepted message corresponds to a from determining whether an intercepted message corresponds to a
predetermined plaintext value. predetermined plaintext value.
Appropriate MIC algorithms and identifiers, signature algorithms and Appropriate MIC algorithms and identifiers, signature algorithms and
identifiers, and signed MIC formats are defined in RFC [1115+]. identifiers, and signed MIC formats are defined in RFC 1423.
A "MIC-Info:" field will occur after a sequence of fields beginning A "MIC-Info:" field will occur after a sequence of fields beginning
with a "Originator-ID-Asymmetric:" or "Originator-Certificate:" field with a "Originator-ID-Asymmetric:" or "Originator-Certificate:" field
and followed by any associated "Issuer-Certificate:" fields. A and followed by any associated "Issuer-Certificate:" fields. A
"MIC-Info:" field applies to all subsequent recipients for whom "MIC-Info:" field applies to all subsequent recipients for whom
asymmetric key management is used, until and unless overridden by a asymmetric key management is used, until and unless overridden by a
subsequent "Originator-ID-Asymmetric:" or "Originator-Certificate:" subsequent "Originator-ID-Asymmetric:" or "Originator-Certificate:"
and corresponding "MIC-Info:". and corresponding "MIC-Info:".
4.6.3 Encapsulated Header Fields with Variable Occurrences 4.6.3 Encapsulated Header Fields with Variable Occurrences
skipping to change at page 36, line 21 skipping to change at page 29, line 21
the certificate carried in the message's "Originator-Certificate:" the certificate carried in the message's "Originator-Certificate:"
field, for recipients' use in chaining through that certificate's field, for recipients' use in chaining through that certificate's
certification path. Other "Issuer-Certificate:" fields, typically certification path. Other "Issuer-Certificate:" fields, typically
representing higher points in a certification path, also may be representing higher points in a certification path, also may be
included by an originator. It is recommended that the "Issuer- included by an originator. It is recommended that the "Issuer-
Certificate:" fields be included in an order corresponding to Certificate:" fields be included in an order corresponding to
successive points in a certification path leading from the originator successive points in a certification path leading from the originator
to a common point shared with the message's recipients (i.e., the to a common point shared with the message's recipients (i.e., the
Internet Certification Authority (ICA), unless a lower Policy Internet Certification Authority (ICA), unless a lower Policy
Certification Authority (PCA) or CA is common to all recipients.) Certification Authority (PCA) or CA is common to all recipients.)
More information on certification paths can be found in RFC [1114+]. More information on certification paths can be found in RFC 1422.
The certificate is represented in the same manner as defined for the The certificate is represented in the same manner as defined for the
"Originator-Certificate:" field (transporting an encoded "Originator-Certificate:" field (transporting an encoded
representation of the certificate in X.509 [7] DER form), and any representation of the certificate in X.509 [7] DER form), and any
"Issuer-Certificate:" fields will ordinarily follow the "Originator- "Issuer-Certificate:" fields will ordinarily follow the "Originator-
Certificate:" field directly. Use of the "Issuer-Certificate:" field Certificate:" field directly. Use of the "Issuer-Certificate:" field
is optional even when asymmetric key management is employed, although is optional even when asymmetric key management is employed, although
its incorporation is strongly recommended in the absence of alternate its incorporation is strongly recommended in the absence of alternate
directory server facilities from which recipients can access issuers' directory server facilities from which recipients can access issuers'
certificates. certificates.
skipping to change at page 38, line 37 skipping to change at page 31, line 10
a MIC. The IK Use Indicator identifies the algorithm and mode in 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 which the identified IK was used for DEK and MIC encryption for a
particular recipient. The MIC Algorithm Indicator identifies the MIC particular recipient. The MIC Algorithm Indicator identifies the MIC
computation algorithm used for a particular recipient. The DEK and computation algorithm used for a particular recipient. The DEK and
MIC are symmetrically encrypted under the IK identified by a MIC are symmetrically encrypted under the IK identified by a
preceding "Recipient-ID-Symmetric:" field and/or prior "Originator- preceding "Recipient-ID-Symmetric:" field and/or prior "Originator-
ID-Symmetric:" field. ID-Symmetric:" field.
Appropriate symmetric encryption algorithms, modes and identifiers, Appropriate symmetric encryption algorithms, modes and identifiers,
MIC computation algorithms and identifiers, and encrypted DEK and MIC MIC computation algorithms and identifiers, and encrypted DEK and MIC
formats are defined in RFC [1115+]. formats are defined in RFC 1423.
4.6.4.2.2 Asymmetric Key Management 4.6.4.2.2 Asymmetric Key Management
When asymmetric key management is employed for a given recipient, the When asymmetric key management is employed for a given recipient, the
"Key-Info:" field transfers two quantities, separated by a comma. "Key-Info:" field transfers two quantities, separated by a comma.
The first argument is an IK Use Indicator identifying the algorithm The first argument is an IK Use Indicator identifying the algorithm
and mode in which the DEK is asymmetrically encrypted. The second and mode in which the DEK is asymmetrically encrypted. The second
argument is a DEK, asymmetrically encrypted under the recipient's argument is a DEK, asymmetrically encrypted under the recipient's
public component. public component.
Appropriate asymmetric encryption algorithms and identifiers, and Appropriate asymmetric encryption algorithms and identifiers, and
encrypted DEK formats are defined in RFC [1115+]. encrypted DEK formats are defined in RFC 1423.
5 Key Management 5. Key Management
Several cryptographic constructs are involved in supporting the PEM Several cryptographic constructs are involved in supporting the PEM
message processing procedure. A set of fundamental elements is message processing procedure. A set of fundamental elements is
assumed. Data Encrypting Keys (DEKs) are used to encrypt message assumed. Data Encrypting Keys (DEKs) are used to encrypt message
text and (for some MIC computation algorithms) in the message text and (for some MIC computation algorithms) in the message
integrity check (MIC) computation process. Interchange Keys (IKs) integrity check (MIC) computation process. Interchange Keys (IKs)
are used to encrypt DEKs and MICs for transmission with messages. In are used to encrypt DEKs and MICs for transmission with messages. In
a certificate-based asymmetric key management architecture, a certificate-based asymmetric key management architecture,
certificates are used as a means to provide entities' public certificates are used as a means to provide entities' public
components and other information in a fashion which is securely bound components and other information in a fashion which is securely bound
skipping to change at page 41, line 15 skipping to change at page 32, line 47
invertible by all recipients, since the originator's certificate invertible by all recipients, since the originator's certificate
provides all recipients with the public component required to perform provides all recipients with the public component required to perform
MIC validation. MIC validation.
This RFC does not prescribe the means by which interchange keys are This RFC does not prescribe the means by which interchange keys are
made available to appropriate parties; such means may be centralized made available to appropriate parties; such means may be centralized
(e.g., via key management servers) or decentralized (e.g., via (e.g., via key management servers) or decentralized (e.g., via
pairwise agreement and direct distribution among users). In any pairwise agreement and direct distribution among users). In any
case, any given IK component is associated with a responsible Issuing case, any given IK component is associated with a responsible Issuing
Authority (IA). When certificate-based asymmetric key management, as Authority (IA). When certificate-based asymmetric key management, as
discussed in RFC [1114+], is employed, the IA function is performed discussed in RFC [1422, is employed, the IA function is performed by
by a Certification Authority (CA). a Certification Authority (CA).
When an IA generates and distributes an IK component, associated When an IA generates and distributes an IK component, associated
control information is provided to direct how it is to be used. In 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, order to select the appropriate IK(s) to use in message encryption,
an originator must retain a correspondence between IK components and an originator must retain a correspondence between IK components and
the recipients with which they are associated. Expiration date the recipients with which they are associated. Expiration date
information must also be retained, in order that cached entries may information must also be retained, in order that cached entries may
be invalidated and replaced as appropriate. be invalidated and replaced as appropriate.
Since a message may be sent with multiple IK components identified, Since a message may be sent with multiple IK components identified,
skipping to change at page 45, line 20 skipping to change at page 36, line 8
receipt of a message encrypted using that IK component, as this would receipt of a message encrypted using that IK component, as this would
render the message permanently undecipherable. Access to an expired render the message permanently undecipherable. Access to an expired
IK component would be needed, for example, to process mail received IK component would be needed, for example, to process mail received
by a user (or system) which had been inactive for an extended period 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 of time. In order to enable very old IK components to be deleted, a
message's recipient desiring encrypted local long term storage should message's recipient desiring encrypted local long term storage should
transform the DEK used for message text encryption via re-encryption transform the DEK used for message text encryption via re-encryption
under a locally maintained IK, rather than relying on IA maintenance under a locally maintained IK, rather than relying on IA maintenance
of old IK components for indefinite periods. of old IK components for indefinite periods.
6 User Naming 6. User Naming
Unique naming of electronic mail users, as is needed in order to Unique naming of electronic mail users, as is needed in order to
select corresponding keys correctly, is an important topic and one select corresponding keys correctly, is an important topic and one
which has received (and continues to receive) significant study. For which has received (and continues to receive) significant study. For
the symmetric case, IK components are identified in PEM headers the symmetric case, IK components are identified in PEM headers
through use of mailbox specifiers in traditional Internet-wide form through use of mailbox specifiers in traditional Internet-wide form
("user@domain-qualified-host"). Successful operation in this mode ("user@domain-qualified-host"). Successful operation in this mode
relies on users (or their PEM implementations) being able to relies on users (or their PEM implementations) being able to
determine the universal-form names corresponding to PEM originators determine the universal-form names corresponding to PEM originators
and recipients. If a PEM implementation operates in an environment and recipients. If a PEM implementation operates in an environment
where addresses in a local form differing from the universal form are where addresses in a local form differing from the universal form are
used, translations must be performed in order to map between the used, translations must be performed in order to map between the
universal form and that local representation. universal form and that local representation.
The use of user identifiers unrelated to the hosts on which the The use of user identifiers unrelated to the hosts on which the
users' mailboxes reside offers generality and value. X.500 users' mailboxes reside offers generality and value. X.500
distinguished names, as employed in the certificates of the distinguished names, as employed in the certificates of the
recommended key management infrastructure defined in RFC [1114+], recommended key management infrastructure defined in RFC 1422,
provide a basis for such user identification. As directory services provide a basis for such user identification. As directory services
become more pervasive, they will offer originators a means to search become more pervasive, they will offer originators a means to search
for desired recipients which is based on a broader set of attributes for desired recipients which is based on a broader set of attributes
than mailbox specifiers alone. Future work is anticipated in than mailbox specifiers alone. Future work is anticipated in
integration with directory services, particularly the mechanisms and integration with directory services, particularly the mechanisms and
naming schema of the Internet OSI directory pilot activity. naming schema of the Internet OSI directory pilot activity.
7 Example User Interface and Implementation 7. Example User Interface and Implementation
In order to place the mechanisms and approaches discussed in this RFC In order to place the mechanisms and approaches discussed in this RFC
into context, this section presents an overview of a hypothetical into context, this section presents an overview of a hypothetical
prototype implementation. This implementation is a standalone prototype implementation. This implementation is a standalone
program which is invoked by a user, and lies above the existing program which is invoked by a user, and lies above the existing
UA sublayer. In the UNIX(tm) system, and possibly in other UA sublayer. In the UNIX system, and possibly in other environments
environments as well, such a program can be invoked as a "filter" as well, such a program can be invoked as a "filter" within an
within an electronic mail UA or a text editor, simplifying the electronic mail UA or a text editor, simplifying the sequence of
sequence of operations which must be performed by the user. This operations which must be performed by the user. This form of
form of integration offers the advantage that the program can be integration offers the advantage that the program can be used in
used in conjunction with a range of UA programs, rather than being conjunction with a range of UA programs, rather than being
compatible only with a particular UA. compatible only with a particular UA.
When a user wishes to apply privacy enhancements to an outgoing When a user wishes to apply privacy enhancements to an outgoing
message, the user prepares the message's text and invokes the message, the user prepares the message's text and invokes the
standalone program, which in turn generates output suitable for standalone program, which in turn generates output suitable for
transmission via the UA. When a user receives a PEM message, the UA transmission via the UA. When a user receives a PEM message, the UA
delivers the message in encrypted form, suitable for decryption and delivers the message in encrypted form, suitable for decryption and
associated processing by the standalone program. associated processing by the standalone program.
In this prototype implementation, a cache of IK components is In this prototype implementation, a cache of IK components is
skipping to change at page 47, line 19 skipping to change at page 37, line 34
Options and destination addresses are selected by command line Options and destination addresses are selected by command line
arguments to the standalone program. The function of specifying arguments to the standalone program. The function of specifying
destination addresses to the privacy enhancement program is logically destination addresses to the privacy enhancement program is logically
distinct from the function of specifying the corresponding addresses distinct from the function of specifying the corresponding addresses
to the UA for use by the MTS. This separation results from the fact to the UA for use by the MTS. This separation results from the fact
that, in many cases, the local form of an address as specified to a 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- UA differs from the Internet global form as used in "Originator-ID-
Symmetric:" and "Recipient-ID-Symmetric:" fields. Symmetric:" and "Recipient-ID-Symmetric:" fields.
8 Minimum Essential Requirements 8. Minimum Essential Requirements
This section summarizes particular capabilities which an This section summarizes particular capabilities which an
implementation must provide for full conformance with this RFC. implementation must provide for full conformance with this RFC.
RFC [1114+] specifies asymmetric, certificate-based key management RFC 1422 specifies asymmetric, certificate-based key management
procedures to support the message processing procedures defined in procedures to support the message processing procedures defined in
this document; PEM implementation support for these key management this document; PEM implementation support for these key management
procedures is strongly encouraged. Implementations supporting these procedures is strongly encouraged. Implementations supporting these
procedures must also be equipped to display the names of originator 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 and recipient PEM users in the X.500 DN form as authenticated by the
procedures of RFC [1114+]. procedures of RFC 1422.
The message processing procedures defined here can also be used with The message processing procedures defined here can also be used with
symmetric key management techniques, though no RFCs analogous to RFC symmetric key management techniques, though no RFCs analogous to RFC
[1114+] are currently available to provide correspondingly detailed 1422 are currently available to provide correspondingly detailed
description of suitable symmetric key management procedures. A description of suitable symmetric key management procedures. A
complete PEM implementation must support at least one of these complete PEM implementation must support at least one of these
asymmetric and/or symmetric key management modes. asymmetric and/or symmetric key management modes.
A full implementation of PEM is expected to be able to send and A full implementation of PEM is expected to be able to send and
receive ENCRYPTED, MIC-ONLY, and MIC-CLEAR messages, and to receive receive ENCRYPTED, MIC-ONLY, and MIC-CLEAR messages, and to receive
CRL messages. Some level of support for generating and processing CRL messages. Some level of support for generating and processing
nested and annotated PEM messages (for forwarding purposes) is to be nested and annotated PEM messages (for forwarding purposes) is to be
provided, and an implementation should be able to reduce ENCRYPTED provided, and an implementation should be able to reduce ENCRYPTED
messages to MIC-ONLY or MIC-CLEAR for forwarding. Fully-conformant messages to MIC-ONLY or MIC-CLEAR for forwarding. Fully-conformant
implementations must be able to emit Certificate and Issuer- implementations must be able to emit Certificate and Issuer-
Certificate fields, and to include a Key-Info field corresponding to Certificate fields, and to include a Key-Info field corresponding to
the originator, but users or configurers of PEM implementations may the originator, but users or configurers of PEM implementations may
be allowed the option of deactivating those features. be allowed the option of deactivating those features.
9 Descriptive Grammar 9. Descriptive Grammar
This section provides a grammar describing the construction of a PEM This section provides a grammar describing the construction of a PEM
message. message.
; PEM BNF representation, using RFC 822 notation. ; PEM BNF representation, using RFC 822 notation.
; imports field meta-syntax (field, field-name, field-body, ; imports field meta-syntax (field, field-name, field-body,
; field-body-contents) from RFC-822, sec. 3.2 ; field-body-contents) from RFC-822, sec. 3.2
; imports DIGIT, ALPHA, CRLF, text from RFC-822 ; imports DIGIT, ALPHA, CRLF, text from RFC-822
; Note: algorithm and mode specifiers are officially defined in RFC [1115+] ; Note: algorithm and mode specifiers are officially defined
; in RFC 1423
<pemmsg> ::= <preeb> <pemmsg> ::= <preeb>
<pemhdr> <pemhdr>
[CRLF <pemtext>] ; absent for CRL message [CRLF <pemtext>] ; absent for CRL message
<posteb> <posteb>
<preeb> ::= "-----BEGIN PRIVACY-ENHANCED MESSAGE-----" CRLF <preeb> ::= "-----BEGIN PRIVACY-ENHANCED MESSAGE-----" CRLF
<posteb> ::= "-----END PRIVACY-ENHANCED MESSAGE-----" CRLF / <preeb> <posteb> ::= "-----END PRIVACY-ENHANCED MESSAGE-----" CRLF / <preeb>
<pemtext> ::= <encbinbody> ; for ENCRYPTED or MIC-ONLY messages <pemtext> ::= <encbinbody> ; for ENCRYPTED or MIC-ONLY messages
skipping to change at page 49, line 4 skipping to change at page 38, line 44
<preeb> ::= "-----BEGIN PRIVACY-ENHANCED MESSAGE-----" CRLF <preeb> ::= "-----BEGIN PRIVACY-ENHANCED MESSAGE-----" CRLF
<posteb> ::= "-----END PRIVACY-ENHANCED MESSAGE-----" CRLF / <preeb> <posteb> ::= "-----END PRIVACY-ENHANCED MESSAGE-----" CRLF / <preeb>
<pemtext> ::= <encbinbody> ; for ENCRYPTED or MIC-ONLY messages <pemtext> ::= <encbinbody> ; for ENCRYPTED or MIC-ONLY messages
/ *(<text> CRLF) ; for MIC-CLEAR / *(<text> CRLF) ; for MIC-CLEAR
<pemhdr> ::= <normalhdr> / <crlhdr> <pemhdr> ::= <normalhdr> / <crlhdr>
<normalhdr> ::= <proctype> <normalhdr> ::= <proctype>
<contentdomain> <contentdomain>
[<dekinfo>] ; needed if ENCRYPTED [<dekinfo>] ; needed if ENCRYPTED
(1*(<origflds> *<recipflds>)) ; symmetric case -- (1*(<origflds> *<recipflds>)) ; symmetric case --
; recipflds included for all proc types ; recipflds included for all proc types
/ ((1*<origflds>) *(<recipflds>)) ; asymmetric case -- / ((1*<origflds>) *(<recipflds>)) ; asymmetric case --
; recipflds included for ENCRYPTED proc type ; recipflds included for ENCRYPTED proc type
<crlhdr> ::= <proctype> <crlhdr> ::= <proctype>
1*(<crl> [<cert>] *(<issuercert>)) 1*(<crl> [<cert>] *(<issuercert>))
<asymmorig> ::= <origid-asymm> / <cert> <asymmorig> ::= <origid-asymm> / <cert>
<origflds> ::= <asymmorig> [<keyinfo>] *(<issuercert>) <micinfo> ; asymmetric <origflds> ::= <asymmorig> [<keyinfo>] *(<issuercert>)
<micinfo> ; asymmetric
/ <origid-symm> [<keyinfo>] ; symmetric / <origid-symm> [<keyinfo>] ; symmetric
<recipflds> ::= <recipid> <keyinfo> <recipflds> ::= <recipid> <keyinfo>
; definitions for PEM header fields ; definitions for PEM header fields
<proctype> ::= "Proc-Type" ":" "4" "," <pemtypes> CRLF <proctype> ::= "Proc-Type" ":" "4" "," <pemtypes> CRLF
<contentdomain> ::= "Content-Domain" ":" <contentdescrip> CRLF <contentdomain> ::= "Content-Domain" ":" <contentdescrip> CRLF
<dekinfo> ::= "DEK-Info" ":" <dekalgid> [ "," <dekparameters> ] CRLF <dekinfo> ::= "DEK-Info" ":" <dekalgid> [ "," <dekparameters> ] CRLF
<symmid> ::= <IKsubfld> "," [<IKsubfld>] "," [<IKsubfld>] <symmid> ::= <IKsubfld> "," [<IKsubfld>] "," [<IKsubfld>]
<asymmid> ::= <IKsubfld> "," <IKsubfld> <asymmid> ::= <IKsubfld> "," <IKsubfld>
<origid-asymm> ::= "Originator-ID-Asymmetric" ":" <asymmid> CRLF <origid-asymm> ::= "Originator-ID-Asymmetric" ":" <asymmid> CRLF
<origid-symm> ::= "Originator-ID-Symmetric" ":" <symmid> CRLF <origid-symm> ::= "Originator-ID-Symmetric" ":" <symmid> CRLF
<recipid> ::= <recipid-asymm> / <recipid-symm> <recipid> ::= <recipid-asymm> / <recipid-symm>
<recipid-asymm> ::= "Recipient-ID-Asymmetric" ":" <asymmid> CRLF <recipid-asymm> ::= "Recipient-ID-Asymmetric" ":" <asymmid> CRLF
<recipid-symm> ::= "Recipient-ID-Symmetric" ":" <symmid> CRLF <recipid-symm> ::= "Recipient-ID-Symmetric" ":" <symmid> CRLF
<cert> ::= "Originator-Certificate" ":" <encbin> CRLF <cert> ::= "Originator-Certificate" ":" <encbin> CRLF
<issuercert> ::= "Issuer-Certificate" ":" <encbin> CRLF <issuercert> ::= "Issuer-Certificate" ":" <encbin> CRLF
<micinfo> ::= "MIC-Info" ":" <micalgid> "," <ikalgid> "," <micinfo> ::= "MIC-Info" ":" <micalgid> "," <ikalgid> ","
<asymsignmic> CRLF <asymsignmic> CRLF
<keyinfo> ::= "Key-Info" ":" <ikalgid> "," <micalgid> "," ; symmetric case <keyinfo> ::= "Key-Info" ":" <ikalgid> "," <micalgid> ","
<symencdek> "," <symencmic> CRLF / <symencdek> "," <symencmic> CRLF ; symmetric case
"Key-Info" ":" <ikalgid> "," <asymencdek> CRLF ; asymmetric case / "Key-Info" ":" <ikalgid> "," <asymencdek>
CRLF ; asymmetric case
<crl> ::= "CRL" ":" <encbin> CRLF <crl> ::= "CRL" ":" <encbin> CRLF
<pemtypes> ::= "ENCRYPTED" / "MIC-ONLY" / "MIC-CLEAR" / "CRL" <pemtypes> ::= "ENCRYPTED" / "MIC-ONLY" / "MIC-CLEAR" / "CRL"
<encbinchar> ::= ALPHA / DIGIT / "+" / "/" / "=" <encbinchar> ::= ALPHA / DIGIT / "+" / "/" / "="
<encbingrp> ::= 4*4<encbinchar> <encbingrp> ::= 4*4<encbinchar>
<encbin> ::= 1*<encbingrp> <encbin> ::= 1*<encbingrp>
<encbinbody> ::= *(16*16<encbingrp> CRLF) [1*16<encbingrp> CRLF] <encbinbody> ::= *(16*16<encbingrp> CRLF) [1*16<encbingrp> CRLF]
<IKsubfld> ::= 1*<ia-char> <IKsubfld> ::= 1*<ia-char>
; Note: "," removed from <ia-char> set so that Orig-ID and Recip-ID fields ; Note: "," removed from <ia-char> set so that Orig-ID and Recip-ID
; can be delimited with commas (not colons) like all other fields ; fields can be delimited with commas (not colons) like all other
; fields
<ia-char> ::= DIGIT / ALPHA / "'" / "+" / "(" / ")" / <ia-char> ::= DIGIT / ALPHA / "'" / "+" / "(" / ")" /
"." / "/" / "=" / "?" / "-" / "@" / "." / "/" / "=" / "?" / "-" / "@" /
"%" / "!" / '"' / "_" / "<" / ">" "%" / "!" / '"' / "_" / "<" / ">"
<hexchar> ::= DIGIT / "A" / "B" / "C" / "D" / "E" / "F" ; no lower case <hexchar> ::= DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
; no lower case
; This specification defines one value ("RFC822") for <contentdescrip>: ; This specification defines one value ("RFC822") for
; other values may be defined in future in separate or successor documents ; <contentdescrip>: other values may be defined in future in
; separate or successor documents
; ;
<contentdescrip> ::= "RFC822" <contentdescrip> ::= "RFC822"
; The following items are defined in RFC [1115+] ; The following items are defined in RFC 1423
; <dekalgid> ; <dekalgid>
; <dekparameters> ; <dekparameters>
; <micalgid> ; <micalgid>
; <ikalgid> ; <ikalgid>
; <asymsignmic> ; <asymsignmic>
; <symencdek> ; <symencdek>
; <symencmic> ; <symencmic>
; <asymencdek> ; <asymencdek>
NOTES: NOTES:
[1] Key generation for MIC computation and message text encryption [1] Key generation for MIC computation and message text encryption
may either be performed by the sending host or by a may either be performed by the sending host or by a
centralized server. This RFC does not constrain this design centralized server. This RFC does not constrain this design
alternative. Section 5.1 identifies possible advantages of a alternative. Section 5.1 identifies possible advantages of a
centralized server approach if symmetric key management is centralized server approach if symmetric key management is
employed. employed.
[2] Postel, J., Simple Mail Transfer Protocol (RFC 821), August [2] Postel, J., "Simple Mail Transfer Protocol", STD 10,
1982. RFC 821, August 1982.
[3] This transformation should occur only at an SMTP endpoint, not [3] This transformation should occur only at an SMTP endpoint, not
at an intervening relay, but may take place at a gateway at an intervening relay, but may take place at a gateway
system linking the SMTP realm with other environments. system linking the SMTP realm with other environments.
[4] Use of a canonicalization procedure similar to that of SMTP [4] Use of a canonicalization procedure similar to that of SMTP
was selected because its functions are widely used and was selected because its functions are widely used and
implemented within the Internet mail community, not for implemented within the Internet mail community, not for
purposes of SMTP interoperability with this intermediate purposes of SMTP interoperability with this intermediate
result. result.
[5] Crocker, D., Standard for the Format of ARPA Internet Text [5] Crocker, D., "Standard for the Format of ARPA Internet Text
Messages (RFC 822), August 1982. Messages", STD 11, RFC 822, August 1982.
[6] Rose, M. T. and Stefferud, E. A., Proposed Standard for Message [6] Rose, M. T. and Stefferud, E. A., "Proposed Standard for
Encapsulation (RFC 934), January 1985. Message Encapsulation", RFC 934, January 1985.
[7] CCITT Recommendation X.509 (1988), "The Directory - [7] CCITT Recommendation X.509 (1988), "The Directory -
Authentication Framework". Authentication Framework".
[8] Throughout this RFC we have adopted the terms "private [8] Throughout this RFC we have adopted the terms "private
component" and "public component" to refer to the quantities component" and "public component" to refer to the quantities
which are, respectively, kept secret and made publicly which are, respectively, kept secret and made publicly
available in asymmetric cryptosystems. This convention is available in asymmetric cryptosystems. This convention is
adopted to avoid possible confusion arising from use of the adopted to avoid possible confusion arising from use of the
term "secret key" to refer to either the former quantity or to term "secret key" to refer to either the former quantity or to
a key in a symmetric cryptosystem. a key in a symmetric cryptosystem.
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.
Security Considerations
This entire document is about security.
Author's Address
John Linn
EMail: 104-8456@mcimail.com
 End of changes. 60 change blocks. 
105 lines changed or deleted 94 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/