Enclosed below is the final draft of the PEM/MIME specification before
the IETF meeting. With this message I would like to ask Steve Kent to
include on the PEM WG agenda time for the discussion (and advancement)
of this specification.
In addition, I would like to update the internet drafts directory. The
document enclosed below replaces the document in the file:
draft-ietf-pem-mime-03.txt
Thus, the name of the file for this document becomes:
draft-ietf-pem-mime-04.txt
as indicated in the document below. Yes, the title has changed but it
is the same document.
Thanks,
Jim
Network Working Group Steve Crocker
INTERNET DRAFT Ned Freed
draft-ietf-pem-mime-04.txt Jim Galvin
Sandy Murphy
Marshall Rose
March 1994
PEM Security Services and MIME
1. 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 valid for a maximum of six months and may be
updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet Drafts as reference material or to cite
them other than as ``work in progress''.
To learn the current status of any Internet Draft, please check the
1id-abstracts.txt listing contained in one of the Internet Drafts Shadow
Directories on ds.internic.net (US East Coast), venera.isi.edu (US West
Coast), munnari.oz.au (Pacific Rim), or nic.nordu.net (Europe).
2. Abstract
This memo defines a new content type for specifying the application of
security services to MIME message bodies. MIME, an acronym for
"Multipurpose Internet Mail Extensions", defines the format of the
contents of Internet mail messages and provides for multi-part textual
and non-textual message bodies. The new content type is a subtype of
multipart called security. It will contain two body parts: one for the
data to be security enhanced and one for the control information
necessary to apply and remove the security enhancement. Initially, two
control information content types are defined: application/signature and
application/keys. The first is to be used when a body part is digitally
signed while the second is to be used when a body part is encrypted.
The new content type is used to specify how the services of MIME and PEM
can be used in a complementary fashion. PEM, an acronym for "Privacy
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 1]
INTERNET DRAFT PEM and MIME February 1994
Enhanced Mail", provides message encryption and message
authentication/integrity services for Internet mail messages. This memo
updates the message encryption and authentication procedures defined by
Part I of the PEM specifications [3] and obsoletes the key certification
and related services defined by Part IV of the PEM specifications [6].
3. Introduction
An Internet electronic mail message consists of two parts: the headers
and the body. The headers form a collection of field/value pairs
structured according to RFC 822 [1], whilst the body, if structured, is
defined according to MIME [2]. MIME does not provide for the
application of security services.
This memo defines a framework whereby security services provided by
other protocols may be used with MIME in a complementary fashion. The
resulting combined service provides security for single-part and multi-
part textual and non-textual messages.
The framework is provided by defining a new subtype of the MIME
multipart content type: security. The security subtype of multipart is
a multipart family [7]. Multipart families always contain at least two
body parts, where the body parts are dependent and one of the body parts
gives instructions for the processing of all the body parts. In the
security subtype, there are exactly two body parts: one content for the
enhanced data and one content for the control information.
The multipart/security content type specifies how to support digital
signature and encryption security services. These services are
supported by defining two control information content types, one for
each of the security services.
PEM [3-6] specifies how to apply encryption and authentication/integrity
services to the contents of a textual electronic mail message but does
not provide message structuring or type labelling facilities. This memo
specifies how to use PEM with the multipart/security content type to
provide encryption and authentication/integrity services. We refer to
the authentication/integrity service as a signature service.
This memo updates the message encryption and signature procedures
defined by [3] and obsoletes the key certification and related services
defined by [6]. The changes include the separation of the encryption
and signature services, the removal of the limitation to enhance only
text-based messages, the removal of the canonicalization and transfer
encoding operations, the deprecation of the Content-Domain: and Proc-
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 2]
INTERNET DRAFT PEM and MIME February 1994
Type: headers, and the separation of certificate and certificate
revocation list transmission from the security enhancements. These
changes represent a departure in mechanism, not in effect, and are
detailed in Section ??.
In addition to the multipart/security, two more MIME content types are
defined: application/pem-request and application/certificate-data.
These new content types are used to transmit requests for certificate
operations (retrieval, certification, revocation list retrieval, etc.)
and the responses to those requests. These two content types are
independent body parts and are not required to be encapsulated in any
other body part.
The relationship between MIME and PEM is described in terms of two
functions: message composition and message delivery.
4. Definition of Multipart/Security
(1) MIME type name: multipart
(2) MIME subtype name: security
(3) Required parameters: boundary
(4) Optional parameters: none
(5) Encoding considerations: Either 7bit, 8bit, or binary encoding may
be used, depending on the nested part encodings and transport
limitations
(6) Security considerations: Must be treated as opaque while in transit
from an originator to a recipient
This content type contains exactly two body parts. The first body part
contains the security enhanced content. The first part's content type
is defined according to the specification of the second body part. The
specification of the second body part may include additional processing
steps to be performed by an implementation before (after) the
application (removal) of the enhancements, for example, see the
application/keys specification below. As a result, an implementation
may not be able to display the content of this first body part to a
user.
The second body part describes the security enhancement which was
applied to the first body part. The second part's content type is
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 3]
INTERNET DRAFT PEM and MIME February 1994
defined by the specification of the security enhancement.
The syntax and semantics of the boundary parameter is defined in [2].
The entire multipart/security body part must be treated as opaque while
it is in transit from an originator to a recipient. Intermediate
transfer agents must not alter the content of a multipart/security in
any way, including, but not limited to, changing the content transfer
encoding on the body part or any of its encapsulated body parts.
Implementations supporting the origination of multipart/security content
types must provide a mechanism with which a security protocol
implementation may make available the content of each of the body parts.
The choice of mechanism is to be made by the implementation.
Implementations supporting the receipt of multipart/security content
types must locate the second body part and continue processing according
to its content type. If the second body part's content type is not
recognized, an implementation may halt processing of the
multipart/security. If possible, an implementation should continue
processing the first body part, for example, it may attempt to display
it.
Upon receipt, the contents of both body parts, with transfer encodings
removed, must be made available to a processor, as specified by the
content type of the second body part. This process must make available
to the implementation the content of the first body part with
enhancements removed. An implementation must continue processing with
this de-enhanced content, according to the specification of the second
body part content type. The content of the second part is not intended
to be consumed by a user.
NOTE: The reason why an implementation may not be able to display
the received form of the first body part is because the application
of security enhancements may transform a body part. This
transformation will not be described in the MIME headers (Content-
Type: and Content-Transfer-Encoding:) but, rather, will be
described in the content of the second body part. Therefore, an
implementation should wait until the security enhancements have
been removed before attempting to display the content.
4.1. Definition of Security Service Content Types
This memo defines two additional content types, one each for when a
digital signature is applied to a body part and for when encryption is
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 4]
INTERNET DRAFT PEM and MIME February 1994
applied to a body part. These content types are to be used as the
second body part in a multipart/security.
Each of the content types includes a required parameter of "protocol."
It is used to indicate which of the several protocols that may be used
to provide the digital signature and encryption services. The value of
this parameter is specified by the protocol definition, not by this
memo.
This memo defines the use of these content types inside a
multipart/security content type. Their use outside a multipart/security
is not defined by this memo.
4.1.1. Application/Signature Content Type
(1) MIME type name: application
(2) MIME subtype name: signature
(3) Required parameters: protocol
(4) Optional parameters: none
(5) Encoding considerations: any valid encoding may be used
(6) Security considerations: none
This content type is used in the second body part of an enclosing
multipart/security. It is comprised of the digital signature of the
data, located in first body part of the enclosing multipart/security,
and the information required to verify that signature. In order to
process this body part, an implementation must recognize and proceed
according to the protocol parameter. It is an error for the protocol
parameter to be missing.
The signature protocol is applied only to the content of the other body
part in the enclosing multipart/security, not to its MIME headers. The
content to be digitally signed is transformed into a canonical form and
made available to the signature process according to a local convention.
The signature process must make available to an implementation both the
data content to be inserted in the other body part and the control
information necessary to verify the signature. The MIME headers of the
other body part are not altered by the application of a digital
signature service. The content of the other body part is replaced by
the data content produced by the signature process. The control
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 5]
INTERNET DRAFT PEM and MIME February 1994
information is inserted in this body part.
Transforming the data to be signed into a canonical form is a necessary
and essential step in the digital signature process. The canonical form
must satisfy the property that it is uniquely and unambiguously
representable on both the originator and recipient's host computer.
This is required in order to ensure that both the originator and
recipient have the same data with which to calculate the digital
signature; the originator needs to be able to include the value when
transferring the body part, while the recipient needs to be able to
compare the calculated value with the received value. There are at
least two ways in which the functionality required may be realized.
(1) The originator may prepare the data in a local representation and
then sign this form of the data. The originator can guarantee that
this representation of the data will not be changed if the
originator applies a content transfer encoding to the data. Having
done so, upon receipt, a recipient will have the original
representation of the data as soon as the encoding is removed.
This method is most effective for non-text content types because
they are more likely to require the application of a content
transfer encoding.
(2) The originator may prepare the data in a local representation and
then may transform the data into a form that is more likely to be
acceptable to a recipient. This transformed representation is
signed and transferred to a recipient. Having done so, upon
receipt, a recipient will have a representation of the data
suitable for immediate processing. This method is most effective
for text content types because they are less likely to require the
application of a content transfer encoding. When the content is
not encoded, interoperability with non-MIME and non-PEM aware
recipients is enhanced.
However, when the data to be signed is represented with the "7bit"
transfer encoding value, it presents a special problem. Although "7bit"
means that the data is all represented as short lines of US-ASCII data,
it does not specify a universal line delimiter. Specifically, distinct
platforms are known to use carriage return <CR>, line feed <LF>, and the
two character sequence <CR><LF>. The transformation between line
delimiters is normally handled as part of the message transfer protocol,
for example, SMTP.
The application of the digital signature service requires that the same
line delimiter be used by both the originator and the recipient. This
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 6]
INTERNET DRAFT PEM and MIME February 1994
memo specifies that the two character sequence "<CR><LF>" must be used
as the line delimiter. Thus, the canonicalization transformation for
"7bit" contents is required to include the transformation of the local
line delimiter to the two character sequence "<CR><LF>". This
transformation must be performed by both an originator and a recipient.
4.1.2. Application/Keys Content Type
(1) MIME type name: application
(2) MIME subtype name: keys
(3) Required parameters: protocol
(4) Optional parameters: none
(5) Encoding considerations: any valid encoding may be used
(6) Security considerations: none
This content type is used in the second body part of an enclosing
multipart/security. It is comprised of the data encryption key used to
encrypt the data, located in the first body part of the enclosing
multipart/security, and the information required to perform the
decryption. In order to process this body part, an implementation must
recognize and proceed according to the protocol parameter. It is an
error for the protocol parameter to be missing.
The encryption protocol is applied to the entire other body part,
including the MIME headers. The body part to be encrypted is made
available to the encryption process according to a local convention.
The encryption process must make available to an implementation both the
encrypted data to be inserted in the other body part and the control
information necessary to decrypt it. The encrypted data (comprised of
the entire other body part including its MIME headers) is inserted in
the first body part and is labeled with a content type of
application/octet-stream, which is defined by [2]. The control
information is inserted in the second, application/keys body part.
The MIME headers on the first body part are included in the data to be
encrypted to protect the type of the data that has been encrypted from
disclosure. An implementation that supports the receipt of a
multipart/security body part containing an application/keys body part
must recursively process the data resulting from the decryption.
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 7]
INTERNET DRAFT PEM and MIME February 1994
5. Use of PEM Security Services in MIME
5.1. Use of multipart/security for PEM
The succeeding two sections describe the content of the
application/signature and application/keys in the multipart/security
when PEM services are applied to MIME body parts.
5.1.1. PEM Processing Steps
The following three steps describe the preparation of outbound PEM
messages.
(1) Local Form -- the content of the message is no longer restricted to
text
(2) Canonical Form -- there is no longer a universal canonical form,
since the message content to be security enhanced may be arbitrary;
however, canonicalization of the content is required
(3) Security Services -- either or both of the signature and encryption
service may be applied in any order
Each of these steps is described in detail below.
5.1.1.1. Step 1: Local Form
This step is applicable to both signed contents and encrypted contents.
The message content is created in the system's native format.
5.1.1.2. Step 2: Canonical Form
Prior to the application of the signature service, the content must be
converted to a canonical form, as specified by Section ??. The required
conversion is summarized here for convenience, although the definitive
specification is only contained there.
No canonicalization is required for the encryption service. If both
signature and encryption services are to be applied to a content, the
content must be canonicalized just prior to the signature service. If
the content is encrypted first, the canonicalization occurs before the
signature service and after the encryption service.
If the encoding type of the content is "7bit", the line delimiters must
be converted to a universal canonical form. In particular, lines must
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 8]
INTERNET DRAFT PEM and MIME February 1994
be delimited by the "<CR><LF>" character sequence.
In all other cases, no content conversion is explicitly required.
However, an originator may convert a local form to a form more suitable
for a recipient. Regardless, an originator must ensure that the form of
the content that is signed is either the same form that is received by a
recipient or is re-creatable by the recipient. Preventing alterations
of the content by mail transfer agents while the message is in transit
is easily accomplished by applying one of the MIME transfer encoding
options, for example, base64 or quoted-printable, as recommended by [2].
5.1.1.3. Step 3: Security Services
An implementation must allow a user to select either or both security
services, in either order. The object to be enhanced is prepared by a
MIME implementation and made available to a PEM implementation according
to a local convention. The PEM implementation must produce two outputs:
the data that has been enhanced and the control information necessary to
de-enhance the data. These outputs must be made available to the MIME
implementation which will construct a multipart/security content.
The next two sections specify the syntax of the control information
output by a PEM implementation for each of security services. The
specification is prescribed by the BNF notation as defined in [1],
Sections 2 and 3.3.
5.1.2. Use of application/signature Content Type
When this content type is used, the value of the required parameter
"protocol" is "pem", for example:
Content-Type: application/signature; protocol="pem"
<pemsig>
where the <pemsig> token is defined as follows. The <keyinfo> token of
[3] has been separated into <sigsymkeyinfo> and <asymkeyinfo> tokens.
The productions <micinfo>, <origid-asymm>, <origid-symm>, <recipid-
symm>, and <recipid-asymm> are defined in Section ??.
<pemsig> ::= <version> 1*<sigorigrecipgroups>
<version> ::= "Version:" "5" CRLF
<sigorigrecipgroups> ::=
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 9]
INTERNET DRAFT PEM and MIME February 1994
( 1*(<origsigsymflds> 1*<recipsigsymflds>) ); symmetric
/ (<origid-symm> <sigsymkeyinfo>) ; symmetric
/ ( 1*<origasymflds> ) *<recipasymflds> ) ; asymmetric
<origsigsymflds> ::= <origid-symm> [<sigsymkeyinfo>]; symmetric
<origasymflds> ::=
<origid-asymm> [<asymkeyinfo>] <micinfo> ; asymmetric
<recipsigsymflds> ::= <recipid-symm> <sigsymkeyinfo> ; symmetric
<recipasymflds> ::= <recipid-asymm> <asymkeyinfo> ; asymmetric
<sigsymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <micalgid> ","
[<symencdek>] "," <symencmic> CRLF ; symmetric
<asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek>
CRLF ; asymmetric
For an implementation that supports only asymmetric key management and
does not support keyed MIC algorithms, the headers can be simply
represented by:
<pemsig> ::= <version> (1*<origasymflds>)
<version> ::= "Version:" "5" CRLF
<origasymflds> ::= <origid-asymm> <micinfo>
5.1.3. Use of application/keys Content Type
When this content type is used, the value of the required parameter
"protocol" is "pem", for example:
Content-Type: application/keys; protocol="pem"
<pemkeys>
where the <pemkeys> token is defined as follows. The <keyinfo> token of
[3] has been separated into <encsymkeyinfo> and <asymkeyinfo> tokens.
The productions <dekinfo>, <origid-asymm>, <origid-symm>, <recipid-
symm>, and <recipid-asymm> are defined in Section ??.
<pemkeys> ::= <version> <dekinfo> 1*<encorigrecipgroups>
<version> ::= "Version:" "5" CRLF
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 10]
INTERNET DRAFT PEM and MIME February 1994
<encorigrecipgroups> ::=
( 1*(<origencsymflds> 1*<recipencsymflds>) ); symmetric
/ ( <oridid-symm> <encsymkeyinfo> ) ; symmetric
/ 1*<recipasymflds> ; asymmetric
<origencsymflds> ::= <origid-symm> [<encsymkeyinfo>]; symmetric
<recipencsymflds> ::= <recipid-symm> <encsymkeyinfo> ; symmetric
<recipasymflds> ::= <recipid-asymm> <asymkeyinfo> ; asymmetric
<encsymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," ","
<symencdek> "," CRLF ; symmetric
<asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek>
CRLF ; asymmetric
As we have separated the encryption and signature security services, the
symmetric Key-Info field has no need for the <micalgid> or <symencmic>
arguments for encrypted messages. We preserve the unneeded commas to
maintain backward compatibility with existing parsers.
For an implementation that supports only asymmetric key management and
does not support keyed MIC algorithms, the headers can be simply
represented by:
<pemkeys> ::= <version> <dekinfo> 1*<recipasymflds>
<version> ::= "Version:" "5" CRLF
<recipasymflds> ::= <recipid-asymm> <asymkeyinfo>
5.2. Definition of New Content Types
This memo defines two new content types, the contents of which comprise
a replacement mechanism for [6]. The first content type is
application/pem-request, which replaces the certification request
message and the CRL-retrieval request message. The second content type
is application/certificate-data, which replaces the certification reply
message, the crl-storage request message, and the crl-retrieval reply
message. There were no requirements for a crl-storage reply message and
none are specified in this memo. This memo includes a specification for
a certificate request message, which was previously undefined.
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 11]
INTERNET DRAFT PEM and MIME February 1994
NOTE: 1424 has some descriptive text, especially for certifica-
tion messages, that should be included
5.2.1. application/pem-request Content Type Definition
(1) MIME type name: application
(2) MIME subtype name: pem-request
(3) Required parameters: none
(4) Optional parameters: none
(5) Encoding considerations: 7bit is always sufficient.
(6) Security Considerations: see [3]
The content of this body part corresponds to the following production.
<request> ::= <version>
( <subject> / <issuer> / <certification> )
<version> ::= "Version:" "5" CRLF
<subject> ::= "Subject:" <asymmid> CRLF
<issuer> ::= "Issuer:" <asymmid> CRLF
<certification> ::= "Certification:" <encbin> CRLF
This content type is used to provide for some of the requests described
in [6]. The information in the body part is entirely independent of any
particular enhanced message. As such, the application/pem-request
content type is an independent body part. It is not used in a
multipart/security context containing PEM enhanced messages.
The certification request and crl-retrieval request are provided for
directly. If the content contains a Certification: field it requests
certification of the self-signed certificate in the field value. If the
content contains an Issuer: field it requests the certificate revocation
list chain beginning with the issuer identified in the field value. If
the content contains a Subject: field it requests the certificate chain
beginning with the subject identified in the field value.
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 12]
INTERNET DRAFT PEM and MIME February 1994
The Subject: and Issuer: fields each contain a value of type Name,
encoded according to the Basic Encoding Rules, then in ASCII, as for the
Originator-ID-Asymmetric: field of [3].
The crl-storage request is provided for by the application/certificate-
data content type described in the next section.
In each case, the response can be transmitted in an
application/certificate-data content type. When returning certificate
and certificate revocation list chains, if there exists more than one
chain, several application/certificate-data contents would need to be
returned in the reply, one for each chain.
5.2.2. application/certificate-data Content Type Definition
(1) MIME type name: application
(2) MIME subtype name: certificate-data
(3) Required parameters: none
(4) Optional parameters: none
(5) Encoding considerations: 7bit is always sufficient.
(6) Security Considerations: see [3]
The content of this body part corresponds to the following production.
<certdata> ::= <certchain> / <crlchain>
<certchain> ::= <version> <cert> *( [ <crl> ] <cert> )
<crlchain> ::= <version> 1*( <crl> [ <cert> ] )
<cert> ::= "Certificate:" <encbin> CRLF
<crl> ::= "CRL:" <encbin> CRLF
<version> ::= "Version:" "5" CRLF
This content type is used to transfer certificate or Certificate
Revocation List (CRL) information. This information is entirely
independent of any particular enhanced message. (Note that the converse
is not true: the validity of an enhanced message cannot be determined
without the proper certificates or current CRL information.) As such,
the application/certificate-data content type is an independent body
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 13]
INTERNET DRAFT PEM and MIME February 1994
part. It is not used in a multipart/security context containing PEM
enhanced messages.
The <certchain> production contains one certificate chain. A
certificate chain starts with a certificate and continues with the
certificates of subsequent issuers. Each issuer certificate included
must have issued the preceding certificate. For each issuer, a CRL may
be supplied. A CRL in the chain belongs to the immediately following
issuer. Therefore, it potentially contains the immediately preceding
certificate.
The <crlchain> production contains one certificate revocation list
chain. The CRLs in the chain begin with the requested CRL and continue
with the CRLs of subsequent issuers. The issuer of each CRL is presumed
to have issued a certificate for the issuer of the preceding CRL. For
each CRL, the issuer's certificate may be supplied. A certificate in
the chain must belong to the issuer of the immediately preceding CRL.
The relationship between a certificate and an immediately preceding CRL
is the same in both cases. In a <certchain> the crl's are optional. In
a <crlchain> the certificates are optional.
5.3. Message Processing
When a user composes a message, it is the responsibility of the user
agent to construct a valid MIME message. In particular, Content-Type:
and Content-Transfer-Encoding: headers should be used wherever they are
appropriate. This allows the receiving user agent to unambiguously
interpret the message body and process it accordingly.
Each block of content headers associated with either an RFC822 <message>
or with a MIME <body-part> represents a logical place where security
enhancement can be requested. A security enhancement request associated
with a particular <message> or <body-part> content is taken to apply to
the entire content; it is not possible to security-enhance only a
portion of a body part.
The mechanism used to communicate security enhancement requests to the
pre-submission processor described below is strictly a local
implementation issue. However, the interface between the message
composer and pre-submission processing MUST be trustworthy, since the
message composer relies on pre-submission processing to either perform
the requested security enhancement operation or return an error.
Regardless of the mechanism chosen, great care should be taken to
safeguard against both the release of information that has not received
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 14]
INTERNET DRAFT PEM and MIME February 1994
the requested type of security enhancement as well as tampering with the
enhancement request itself.
5.3.1. Pre-Submission Algorithm
The user agent first composes a MIME-compliant message and then applies
this algorithm:
(1) If the content at this (initially top) level has NOT been selected
for security enhancement, the user agent sees if the content is
either multipart or message. If so, it then recursively applies
this algorithm to the encapsulated body parts; if not, it
terminates processing for this content.
(2) If the content at this level has been selected for security
enhancement, then the content, including its headers, constitutes
the object that is to be made available to the security enhancement
process. The headers at a minimum will include a Content-Type
header, either explicit or implicit. The object will eventually be
replaced with the multipart/security content that is produced by
the security enhancement operation.
(3) The selected security enhancement is performed. This enhancement
produces two data streams: the enhanced object and a control stream
comprised of a set of headers as defined in the <pemsig> or
<pemkeys> productions.
(4) A new body part is then constructed, of content type
multipart/security. The body part contains two body parts, whose
content depends on the enhancement requested, which is constructed
according to the specifications in this memo.
(5) This multipart/security content replaces the original object.
5.3.2. Post-Delivery Algorithm
When a user receives a message containing a multipart/security content,
the user agent may transform the content back into its original form
prior to privacy-enhancement. This operation, the post-delivery
algorithm, is performed by reversing the steps performed during the
pre-submission algorithm.
When the original content is reconstituted, it may use octet values
outside of the US-ASCII repertoire and may contain body parts without
line breaks. If the user agent replaces the multipart/security content
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 15]
INTERNET DRAFT PEM and MIME February 1994
with the original content, then it must select appropriate Content-
Transfer-Encodings for each body part and add corresponding Content-
Transfer-Encoding: headers.
Upon successful completion of the post-delivery algorithm for each
content, the type of enhancement that was in effect for that content
must be communicated to the user. The mechanism used to do this is a
local implementation issue. As with requests for enhancement to the
pre-submission algorithm, the path between post-delivery processing and
actual display of the message must be a trusted one, lest a message be
presented that purports to have undergone some form of enhancement it
did not in fact receive.
5.4. Examples
For example, suppose the following message was selected for security
enhancement:
To: ned(_at_)innosoft(_dot_)com
Subject: example #1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Hi Ned. See how much nicer this works!
After applying pre-submission algorithm with a request that signature
enhancement be applied to the body, the message submitted for delivery
would appear as:
To: ned(_at_)innosoft(_dot_)com
Subject: example #1
MIME-Version: 1.0
Content-Type: multipart/security; boundary="----- =Signature Boundary"
------- =Signature Boundary
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1685(_dot_)762723090(_dot_)2(_at_)tis(_dot_)com>
Hi Ned. See how much nicer this works!
------- =Signature Boundary
Content-Type: application/signature; protocol="pem"
Content-ID: <1685(_dot_)762723090(_dot_)1(_at_)tis(_dot_)com>
Content-Transfer-Encoding: quoted-printable
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 16]
INTERNET DRAFT PEM and MIME February 1994
Version: 5
Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UE=
ChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,0=
2
MIC-Info: RSA-MD5,RSA,qJ8q9mzkH/B+/ntR3xFDwTCOKaIyvIAyPw0ZoseDSCMQ6uDXD9RE=
n3QHrU5IGq1kK8bk4OU13TIh0ke7ZeRriCaypz25KoUGl9S6rUAsDSRo7De9K0FtJDzlJpnPhI=
CB
------- =Signature Boundary--
After applying the post-delivery algorithm, the resulting message would
once again appear as:
To: ned(_at_)innosoft(_dot_)com
Subject: example #1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Hi Ned. See how much nicer this works!
If it was desired to also sign the headers of the example message, after
applying the pre-submission algorithm the message submitted for delivery
would appear as:
To: ned(_at_)innosoft(_dot_)com
Subject: example #1
MIME-Version: 1.0
Content-Type: multipart/security; boundary="----- =Signature Boundary"
------- =Signature Boundary
MIME-Version: 1.0
Content-Type: message/rfc822
Content-ID: <1732(_dot_)762723767(_dot_)2(_at_)tis(_dot_)com>
To: ned(_at_)innosoft(_dot_)com
Subject: example #1
Content-Type: text/plain; charset="us-ascii"
Hi Ned. See how much nicer this works!
------- =Signature Boundary
Content-Type: application/signature; protocol="pem"
Content-ID: <1732(_dot_)762723767(_dot_)1(_at_)tis(_dot_)com>
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 17]
INTERNET DRAFT PEM and MIME February 1994
Content-Transfer-Encoding: quoted-printable
Version: 5
Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UE=
ChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,0=
2
MIC-Info: RSA-MD5,RSA,qOfK2DcyOixFicDp7UII9E0fmX3asfgD1OVgt3kxpZlpPEO055ek=
bZq+eDdEFUrte8TXU00RbKilGlyZnD/1MwDykX+0u9imBbtbJ+Y/hHP/3pKXSHo8lWMlri9hg3=
+C
------- =Signature Boundary--
The content to be enhanced need not be ascii text. For example, the
following audio body part could be signed:
Content-Type: audio/basic
[ binary data representing a sound ]
producing the following body part:
Content-Type: multipart/security; boundary="----- =Signature Boundary"
------- =Signature Boundary
Content-Type: audio/basic
Content-ID: <1747(_dot_)762724129(_dot_)2(_at_)tis(_dot_)com>
Content-Transfer-Encoding: base64
WyBiaW5hcnkgZGF0YSByZXByZXNlbnRpbmcgYSBzb3VuZCBdCg==
------- =Signature Boundary
Content-Type: application/signature; protocol="pem"
Content-ID: <1747(_dot_)762724129(_dot_)1(_at_)tis(_dot_)com>
Content-Transfer-Encoding: quoted-printable
Version: 5
Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UE=
ChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,0=
2
MIC-Info: RSA-MD5,RSA,k6E85mx8fHD+JPxaexmuao9lwAtn1TCL8/7QfUarHW9yhaNH7E0S=
/ID2AmUQexN++R38SegJ4NukhGs6icU9cdrYZ2fvgxHx1ThAthCIt7C8cVJRldHvq72mQ10d82=
0h
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 18]
INTERNET DRAFT PEM and MIME February 1994
------- =Signature Boundary--
Note well, the binary form of the data was signed, not the encoded form.
The content transfer encoding indicated above was applied because
multiparts are required to be 7bit clean. Thus, the encoding must be
removed before the signature is verified by the recipient.
The following content illustrates how a security enhanced content can
itself be security enhanced. The inner most text content is digitally
signed. The outer multipart/security applies a digital signature to the
entire inner signed object.
Content-Type: text/plain; charset="us-ascii"
This text will be signed and then the signed object will be signed.
Application of the pre-submission algorithm produces:
Content-Type: multipart/security; boundary="----- =Outer Signature Boundary"
------- =Outer Signature Boundary
Content-Type: multipart/security; boundary="----- =Inner Signature Boundary"
------- =Inner Signature Boundary
Content-Type: text/plain; charset="us-ascii"
Content-ID: <1759(_dot_)762724555(_dot_)3(_at_)tis(_dot_)com>
This text will be signed and then the signed object will be signed.
------- =Inner Signature Boundary
Content-Type: application/signature; protocol="pem"
Content-ID: <1759(_dot_)762724555(_dot_)2(_at_)tis(_dot_)com>
Content-Transfer-Encoding: quoted-printable
Version: 5
Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UE=
ChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,0=
2
MIC-Info: RSA-MD5,RSA,pBEHvHjrcOs30+jZzy5E2UTAaeb6R7B1wdWbtEcGOqEi2WNrIfBw=
D1gZDueUZTYSyCkEHEnErXsrhGc8jsoqcAHLYg52iYdrMpDBGoXRQobXHNI+Cpnx//s4lp3PAU=
cp
------- =Inner Signature Boundary--
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 19]
INTERNET DRAFT PEM and MIME February 1994
------- =Outer Signature Boundary
Content-Type: application/signature; protocol="pem"
Content-ID: <1759(_dot_)762724555(_dot_)1(_at_)tis(_dot_)com>
Content-Transfer-Encoding: quoted-printable
Version: 5
Originator-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UE=
ChMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,0=
2
MIC-Info: RSA-MD5,RSA,XqedEy0cwHyLdt4+oBGEl+/2BfypRx18RohAElwAZmEgZDEWiFKJ=
ujRh4aAQUCF/U9lR7Z6kyTvSNLBCG8N0D0GxONStUOjUsj7b7vX72bCLnc9wVaeWMvtiA+HFXm=
Le
------- =Outer Signature Boundary--
Suppose the body of the following message was selected for signature and
then encryption:
To: galvin(_at_)tis(_dot_)com
Subject: example #1
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Yes Jim, it works much nicer!
The application of the pre-submission algorithm would produce:
To: galvin(_at_)tis(_dot_)com
Subject: example #1
MIME-Version: 1.0
Content-Type: multipart/security; boundary="----- =Encryption Boundary"
------- =Encryption Boundary
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
yo+jQ2neZQiFW+21/DHev4dumFTAOui7nB+cRfFhJff+5Xpwl5RWxdmzfXWiSB3nBBrsqwHu3yIv
mZONWdRyWlhy2BIpKj54OoyDj0EbmCMseY5v0JPJhMYqf4SoBRHOMGZRsFAEF849diLX4nZhC1lS
ljfF9KGgRi3OBl/JblAtOxehkvvD20Z1kQUtQ/84KYFAKxV6WferRHK+vHxeciOUYMrGa+wipGTU
sPLYm7kuESHyACb0Wihy5RZ+fOkf0LZT1aCX/945nw/CpSWnp83EsyevvXCTYz+EejnOw9GHZTR0
nBnOolfXG7uEv4PaMfcG70Wz+ic+e8rtqHXW8BOA4THGv81fZd0OCBFYc1oRz3SzVRaPVtpiN4LE
8b1tQVuBu8DKdWbGeY0HvHm/SEZ+/Cb2idbOC6Cm89/yz6o1y2dTycClXa2DbHPtuR1FjzpTm8bq
cr5/ycQ1k2gmO4MagKHCAEn+Hq9w9ITSZFNmV/jSQaE7f6lox00snfukK1aXQW4f66b+H0o83stw
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 20]
INTERNET DRAFT PEM and MIME February 1994
adVPFVdFHIMRGMoV/17kfqaUh7LFJr7u7Xbz0geDxT2aFUzYbk1lC6H6XKLnL8Ipbczavq9GELD9
wQkbkHxUUgV9xhTuwXJzRkhpi9FF389nxR9WEoP9S+Be9GeoCPCOHcd5BJhvYKGoBUhuAL9dM6GW
7SLy0QOg/dylJEZ6Hg9FJDSRrNF6xbs+Sxf85p0oKtt+egpVoKRJXub3zniqaKK9k15bFdkZSMLz
cnqZcDG70UgyE7IFVsDL7h+P1p4DKHT60xOowCgZkUOQC98MczB78F1D5GB3s/d++rZ/J0i0v3IO
3BMGHgFHJfMFAgbH5cFBEzkTY3y0L85iDEZ6GQAkP86uCYYVMeEFIokostKrgpF++UdvA5GxbdjO
oZjzLnjjraLtkYB1Ht8iEbxjRIlYAK1YMlm29A==
------- =Encryption Boundary
Content-Type: application/keys; protocol="pem"
Content-ID: <1778(_dot_)762724901(_dot_)1(_at_)tis(_dot_)com>
Content-Transfer-Encoding: quoted-printable
Version: 5
DEK-Info: DES-CBC,933A1AB95512E140
Recipient-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEC=
hMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,02
Key-Info: RSA,r8kCmWCqfe39FYybN7kTOPzVuCw4LXagpCdeYJcy942eKv2hXX8LkplY3f8Q=
E3Z8gkBh3WZjNephpor4rul7UvlKW1t+/IHmcReiWRiwSiBwuuET3o7ScOMAbdZfe8vl
------- =Encryption Boundary--
If the body of the same message was selected for encryption only, the
application of the pre-submission algorithm would produce:
To: galvin(_at_)tis(_dot_)com
Subject: example #1
MIME-Version: 1.0
Content-Type: multipart/security; boundary="----- =Encryption Boundary"
------- =Encryption Boundary
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64
oOsMVFWMmIjvk4gDeXtdQcAb9273rp+0YcFLul2fezlEn2686vuq0EHOYeduSsKYv3H5F8L79r1Y
ZyW0pHo4uPmNiLIJGhXyqh5eBXp18JCqsBJmXOQaBggzscmKNi0xBFzyDOVYXxjAE3449mRdbxsM
fbqo3cPs
------- =Encryption Boundary
Content-Type: application/keys; protocol="pem"
Content-ID: <1803(_dot_)762725084(_dot_)1(_at_)tis(_dot_)com>
Content-Transfer-Encoding: quoted-printable
Version: 5
DEK-Info: DES-CBC,E18A7DA1885E2C49
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 21]
INTERNET DRAFT PEM and MIME February 1994
Recipient-ID-Asymmetric: MFMxCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJNRDEkMCIGA1UEC=
hMbVHJ1c3RlZCBJbmZvcm1hdGlvbiBTeXN0ZW1zMREwDwYDVQQLEwhHbGVud29vZA=3D=3D,02
Key-Info: RSA,BMD6IcGJvpu4ZDMDkLrGaQ66TNNE2yTnw+AjpbWyXEiFT70VEFUUkhwPKJVz=
kVzzEJNzMugkROc3LYbf1kJtsnF+4V34Wqs8nAl60DNrzFGpZfYtnCcIro6eAyVO8y4A
------- =Encryption Boundary--
5.5. Observations
The use of the pre-submission and post-delivery algorithms to combine
PEM and MIME capabilities exhibit several properties:
(1) It allows privacy-enhancement of an arbitrary content, not just an
entire RFC 822 message.
(2) For a multipart or message content, it allows the user to specify
different privacy enhancements to be applied to different
components of the structure of the content.
(3) It provides for messages containing several privacy enhanced
contents, thereby removing the requirement for PEM software to be
able to generate or interpret a single content which intermixes
both unenhanced and enhanced components.
The use of a MIME-capable user agent makes complex nesting of enhanced
message body parts much easier. For example, the user can separately
sign and encrypt a message. This motivates a complete separation of the
confidentiality security service from the authentication/message
integrity security service. That is, different keys could be used for
the different services and could be protected separately. In the
asymmetric case, this means an employee's company could be given access
to the (private) decryption key but not the (private) signature key,
thereby granting the company the ability to decrypt messages addressed
to the employee in emergencies without also granting the company the
ability to sign messages as the employee.
The use of two private keys requires the ability to maintain multiple
certificates for each user.
5.6. Summary of Changes to PEM Specification
This memo updates the message encryption and signature procedures
defined by [3] and obsoletes the key certification and related services
defined by [6]. The changes are enumerated below.
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 22]
INTERNET DRAFT PEM and MIME February 1994
(1) The PEM specification currently requires that encryption services
be applied only to message bodies that have been signed. By
providing for each of the services separately, they may be applied
recursively in any order according to the needs of the requesting
application.
(2) PEM implementations are currently restricted to processing only
text-based electronic mail messages. In fact, the message text is
required to be represented by the ASCII character set with
"<CR><LF>" line delimiters. This restriction no longer applies.
(3) With the removal of the text restriction it is not possible to
specify a universal canonical form. Thus, the transformation of
the input to a universal canonical form no longer applies.
Instead, the content of each body part must be transformed into a
canonical form according to its type.
(4) MIME includes transfer encoding operations to ensure the unmodified
transport of body parts, which obviates these services in PEM.
(5) PEM specifies a Proc-Type: header field to identify the type of
processing that was performed on the message. This functionality
is subsumed by the MIME Content-Type: headers. The Proc-Type:
header also included a decimal number that was used to distinguish
among incompatible encapsulated header field interpretations which
may arise as changes are made to the PEM standard. This
functionality is replaced by the Version: header specified in this
memo.
(6) PEM specifies a Content-Domain: header, the purpose of which is to
describe the type of the content which is represented within a PEM
message's encapsulated text. This functionality is subsumed by the
MIME Content-Type: headers.
(7) The PEM specifications include a document that defines new types of
PEM messages, specified by unique values used in the Proc-Type:
header, to be used to request certificate and certificate
revocation list information. This functionality is subsumed by two
new content types specified in this memo.
(8) The header fields having to do with certificates (Originator-
Certificate: and Issuer-Certificate:) and CRLs (CRL:) are relegated
for use only in the application/certificate-data and
application/pem-request content types and are no longer allowed in
the header portion of a PEM signed or encrypted message.
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 23]
INTERNET DRAFT PEM and MIME February 1994
(9) The grammar specified here explicitly separates the header fields
that may appear for the encryption and signature security services,
and for symmetric and asymmetric key management. It is the intent
of this memo to specify a precise expression of the allowed header
fields; there is no intent to reduce the functionality of
combinations of symmetric and asymmetric key management, and
encryption and signature security from those of [3].
(10) With the separation of the encryption and signature security
services, there is no need for a MIC-Info: field in the headers
associated with an encrypted message under asymmetric key
management.
(11) With the separation of the encryption and signature security
services, there is no need for a <micalgid> argument or a
<symencmic> argument in the Key-Info: field associated with an
originator or recipient with symmetric key management for an
encrypted message.
(12) In [3], when asymmetric key management is used, an Originator-ID
field is required in order to identify the private key used to sign
the MIC argument in the MIC-Info: field. Because no MIC-Info:
field is associated with the encryption security service under
asymmetric key managment, there is no requirement in that case to
include an Originator-ID field.
(13) In [3], when symmetric key management is used, a recipient field is
always required. This memo allows headers which include only an
Originator-ID-Symmetric: field and a Key-Info: field to be used in
those cases where an originator sends a message only to
himself/herself.
These changes represent a departure in mechanism, not in effect, from
those specified in [3] and [6].
5.7. Collected Grammar
The following is a summary of the grammar presented in this document.
(1) Signature headers
<pemsig> ::= <version> 1*<sigorigrecipgroups>
<version> ::= "Version:" "5" CRLF
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 24]
INTERNET DRAFT PEM and MIME February 1994
<sigorigrecipgroups> ::=
( 1*(<origsigsymflds> 1*<recipsigsymflds>) ); symmetric
/ (<origid-symm> <sigsymkeyinfo>) ; symmetric
/ ( 1*<origasymflds> *<recipasymflds> ) ; asymmetric
<origsigsymflds> ::= <origid-symm> [<sigsymkeyinfo>]; symmetric
<origasymflds> ::=
<origid-asymm> [<asymkeyinfo>] <micinfo> ; asymmetric
<recipsigsymflds> ::= <recipid-symm> <sigsymkeyinfo> ; symmetric
<recipasymflds> ::= <recipid-asymm> <asymkeyinfo> ; asymmetric
<sigsymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <micalgid> ","
[<symencdek>] "," <symencmic> CRLF ; symmetric
<asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek>
CRLF ; asymmetric
(2) Signature headers (short version)
<pemsig> ::= <version> (1*<origasymflds>)
<version> ::= "Version:" "5" CRLF
<origasymflds> ::= <origid-asymm> <micinfo>
(3) Encryption Headers
<pemkeys> ::= <version> <dekinfo> 1*<encorigrecipgroups>
<version> ::= "Version:" "5" CRLF
<encorigrecipgroups> ::=
( 1*(<origencsymflds> 1*<recipencsymflds>) ); symmetric
/ ( <oridid-symm> <encsymkeyinfo> ) ; symmetric
/ 1*<recipasymflds> ; asymmetric
<origencsymflds> ::= <origid-symm> [<encsymkeyinfo>]; symmetric
<recipencsymflds> ::= <recipid-symm> <encsymkeyinfo> ; symmetric
<recipasymflds> ::= <recipid-asymm> <asymkeyinfo> ; asymmetric
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 25]
INTERNET DRAFT PEM and MIME February 1994
<encsymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," ","
<symencdek> "," CRLF ; symmetric
<asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek>
CRLF ; asymmetric
(4) Encryption Headers (short version)
<pemkeys> ::= <version> <dekinfo> 1*<recipasymflds>
<version> ::= "Version:" "5" CRLF
<recipasymflds> ::= <recipid-asymm> <asymkeyinfo>
(5) Request Headers (certificate, certification, etc.)
<request> ::= <version>
( <subject> / <issuer> / <certification> )
<version> ::= "Version:" "5" CRLF
<subject> ::= "Subject:" <asymmid> CRLF
<issuer> ::= "Issuer:" <asymmid> CRLF
<certification> ::= "Certification:" <encbin> CRLF
(6) Certificate Headers (certificate, certification revocation list)
<certdata> ::= <certchain> / <crlchain>
<certchain> ::= <version> <cert> *( [ <crl> ] <cert> )
<crlchain> ::= <version> 1*( <crl> [ <cert> ] )
<cert> ::= "Certificate:" <encbin> CRLF
<crl> ::= "CRL:" <encbin> CRLF
<version> ::= "Version:" "5" CRLF
6. Security Considerations
NOTE: to be done
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 26]
INTERNET DRAFT PEM and MIME February 1994
7. Acknowledgements
David H. Crocker suggested the use of a multipart structure for MIME-PEM
interaction.
8. References
[1] David H. Crocker. Standard for the Format of ARPA Internet Text
Messages. RFC 822, University of Delaware, August 1982.
[2] Nathaniel Borenstein and Ned Freed. MIME (Multipurpose Internet
Mail Extension) Part One: Mechanisms for Specifying and Describing
the Format of Internet Message Bodies. RFC 1521, Bellcore and
Innosoft, September 1993. Obsoletes RFC 1341.
[3] John Linn. Privacy Enhancement for Internet Electronic Mail: Part
I: Message Encryption and Authentication Procedures. RFC 1421,
February 1993. Obsoletes RFC 1113.
[4] Steve Kent. Privacy Enhancement for Internet Electronic Mail: Part
II: Certificate-Based Key Management. RFC 1422, BBN
Communications, February 1993.
[5] David M. Balenson. Privacy Enhancement for Internet Electronic
Mail: Part III: Algorithms, Modes, and Identifiers. RFC 1423,
Trusted Information Systems, February 1993.
[6] Burton S. Kaliski. Privacy Enhancement for Internet Electronic
Mail: Part IV: Key Certification and Related Services. RFC 1424,
RSA Laboratories, February 1993.
[7] David Crocker. Multipart/Family Content Types. Work in progress.
9. Authors' Addresses
Steve Crocker
Trusted Information Systems
3060 Washington Road
Glenwood, MD 21738
Tel: +1 301 854 6889
FAX: +1 301 854 5363
email: crocker(_at_)tis(_dot_)com
Ned Freed
Innosoft International, Inc.
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 27]
INTERNET DRAFT PEM and MIME February 1994
250 West First Street, Suite 240
Claremont, CA 91711
Tel: +1 909 624 7907
FAX: +1 909 621 5319
email: ned(_at_)innosoft(_dot_)com
James M. Galvin
Trusted Information Systems
3060 Washington Road
Glenwood, MD 21738
Tel: +1 301 854 6889
FAX: +1 301 854 5363
email: galvin(_at_)tis(_dot_)com
Sandra Murphy
Trusted Information Systems
3060 Washington Road
Glenwood, MD 21738
Tel: +1 301 854 6889
FAX: +1 301 854 5363
email: murphy(_at_)tis(_dot_)com
Marshall T. Rose
Dover Beach Consulting, Inc.
420 Whisman Court
Mountain View, CA 94043-2186
Tel: +1 415 968 1052
FAX: +1 415 968 2510
email: mrose(_at_)dbc(_dot_)mtview(_dot_)ca(_dot_)us
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 28]
INTERNET DRAFT PEM and MIME February 1994
10. Appendix: RFC 1421 Grammar
The following productions are taken from [3]. The grammar presented in
[3] remains the authoritative source for these productions; they are
repeated here for the convenience of the reader.
<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-asymm> ::= "Recipient-ID-Asymmetric" ":" <asymmid> CRLF
<recipid-symm> ::= "Recipient-ID-Symmetric" ":" <symmid> CRLF
<issuercert> ::= "Issuer-Certificate" ":" <encbin> CRLF
<micinfo> ::= "MIC-Info" ":" <micalgid> "," <ikalgid> ","
<asymsignmic> CRLF
<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
; The following items are defined in RFC 1423
; <dekalgid>
; <dekparameters>
; <micalgid>
; <ikalgid>
; <asymsignmic>
; <symencdek>
; <symencmic>
; <asymencdek>
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 29]
INTERNET DRAFT PEM and MIME February 1994
Table of Contents
1 Status of this Memo ............................................. 1
2 Abstract ........................................................ 1
3 Introduction .................................................... 2
4 Definition of Multipart/Security ................................ 3
4.1 Definition of Security Service Content Types .................. 4
4.1.1 Application/Signature Content Type .......................... 5
4.1.2 Application/Keys Content Type ............................... 7
5 Use of PEM Security Services in MIME ............................ 8
5.1 Use of multipart/security for PEM ............................. 8
5.1.1 PEM Processing Steps ........................................ 8
5.1.1.1 Step 1: Local Form ........................................ 8
5.1.1.2 Step 2: Canonical Form .................................... 8
5.1.1.3 Step 3: Security Services ................................. 9
5.1.2 Use of application/signature Content Type ................... 9
5.1.3 Use of application/keys Content Type ........................ 10
5.2 Definition of New Content Types ............................... 11
5.2.1 application/pem-request Content Type Definition ............. 12
5.2.2 application/certificate-data Content Type Definition ........ 13
5.3 Message Processing ............................................ 14
5.3.1 Pre-Submission Algorithm .................................... 15
5.3.2 Post-Delivery Algorithm ..................................... 15
5.4 Examples ...................................................... 16
5.5 Observations .................................................. 22
5.6 Summary of Changes to PEM Specification ....................... 22
5.7 Collected Grammar ............................................. 24
6 Security Considerations ......................................... 26
7 Acknowledgements ................................................ 27
8 References ...................................................... 27
9 Authors' Addresses .............................................. 27
10 Appendix: RFC 1421 Grammar ..................................... 29
Crocker/Freed/Galvin/Murphy/Rose~Expires: September 1994 [Page 30]
binWJhgJa3MeI.bin
Description: application/signature