draft-ietf-pem-mime-05.txt   draft-ietf-pem-mime-06.txt 
Network Working Group Steve Crocker Network Working Group Steve Crocker
INTERNET DRAFT Ned Freed INTERNET DRAFT Ned Freed
draft-ietf-pem-mime-05.txt Jim Galvin draft-ietf-pem-mime-06.txt Jim Galvin
Sandy Murphy Sandy Murphy
PEM Security Services and MIME PEM Security Services and MIME
1. Status of this Memo 1. Status of this Memo
This document is an Internet Draft. Internet Drafts are working This document is an Internet Draft. Internet Drafts are working
documents of the Internet Engineering Task Force (IETF), its Areas, and documents of the Internet Engineering Task Force (IETF), its Areas, and
its Working Groups. Note that other groups may also distribute working its Working Groups. Note that other groups may also distribute working
documents as Internet Drafts. documents as Internet Drafts.
skipping to change at page 2, line 13 skipping to change at page 2, line 13
application of security services. application of security services.
PEM [3-6] specifies how to apply encryption and authentication/integrity PEM [3-6] specifies how to apply encryption and authentication/integrity
services to the contents of a textual electronic mail message but does services to the contents of a textual electronic mail message but does
not provide message structuring or type labelling facilities. This not provide message structuring or type labelling facilities. This
document specifies how to use PEM with the multipart/signed and document specifies how to use PEM with the multipart/signed and
multipart/encrypted MIME content types to provide multipart/encrypted MIME content types to provide
authentication/integrity and encryption services. We refer to the authentication/integrity and encryption services. We refer to the
authentication/integrity service as a digital signature service. authentication/integrity service as a digital signature service.
This document specifies a number of changes to the message encryption
and signature procedures of PEM and broadens the name forms that may be
used to identify public keys. Many of the changes represent a departure
in mechanism, not in effect.
3. Introduction
This document updates the message encryption and signature procedures This document updates the message encryption and signature procedures
defined by [3] and obsoletes the key certification and related services defined by [3] and obsoletes the key certification and related services
defined by [6]. The changes to [3] include the separation of the defined by [6]. The changes to [3] include the separation of the
encryption and signature services, the removal of the limitation to encryption and signature services, the removal of the limitation to
enhance only text-based messages, the removal of the transfer encoding enhance only text-based messages, the removal of the transfer encoding
operation, the deprecation of the Content-Domain: and Proc-Type: operation, the deprecation of the Content-Domain: and Proc-Type:
headers, and the separation of certificate and certificate revocation headers, and the separation of certificate and certificate revocation
list transmission from the security enhancements. These changes list transmission from the security enhancements. These changes
represent a departure in mechanism, not in effect, and are detailed in represent a departure in mechanism, not in effect, and are detailed in
Section ??. Section 10.
In addition, this document proposes three technical changes: in [3] In addition, this document specifies three technical changes to PEM:
symmetric key management is deprecated, also in [3] the canonicalization symmetric key management in [3] is deprecated, the canonicalization
operation is generalized, and in [4] the allowable name forms for the operation in [3] is generalized, and the allowable name forms for the
subjects of certificates is broadened to include arbitrary strings and identification of public keys is broadened to include arbitrary strings
email addresses, and users may distribute their public keys directly in and email addresses, and users may distribute their public keys directly
lieu of certificates. in lieu of certificates.
The key certification and related services document [6] is obsoleted by The key certification and related services document [6] is obsoleted by
the specification of two new MIME content types: application/key-request the specification of two new MIME content types: application/key-request
and application/key-data. These new content types are used to transmit and application/key-data. These new content types are used to transmit
requests for key operations (retrieval, certification, revocation list requests for key operations (storage, retrieval, certification,
retrieval, etc.) and the responses to those requests. These two revocation list retrieval, etc.) and the responses to those requests.
content types are independent body parts and are not required to be These two content types are independent body parts and are not required
encapsulated in any other body part. These changes represent a to be encapsulated in any other body part. These changes represent a
departure in mechanism, not in effect, and are detailed in Section ??. departure in mechanism, not in effect, and are detailed in Section 10.
The relationship between MIME and PEM is described in terms of two In order to make use of the PEM services, a user is required to have at
functions: message composition and message delivery. least one public/private key pair. Prior to this specification, the
public key was required to be embodied in a certificate, an object that
3. Applying PEM Security Services to MIME Body Parts binds a public key with a distinguished name, a name form that
identified the owner of the public key. The embodiment was issued by a
certification authority, a role that was expected to be trustworthy
insofar as it verified the identity of the owner prior to issuing the
certificate. However, the deployment of certificates and the creation
of the hierarchy of certification authorities has been problematic.
Instead, this specification bases the PEM services on a public/private
key pair. Each key pair is required to belong to a user (where user is
not limited to being a human, e.g., a process or a role) which has a
name. There are 3 name forms specified by this document. For backward
compatibility (and forward compatibility if the X.500 Directory becomes
a ubiquitous service) one of the name forms is a distinguished name. In
addition, email addresses and arbitrary strings are allowed.
Since a user may have more than one key pair, a name form is
insufficient for uniquely identifying a key pair. The owner of a key
pair must assign a key identifier to each key pair. The combination of
a name form and a key identifier uniquely identifies a key pair and each
key pair is uniquely identified by a name form and key identifier
combination. Throughout this document, this combination is called an
identifier. There are 6 identifiers specified by this document.
With a key pair for one's self and software that is both MIME and PEM
aware, an originating user may digitally sign arbitrary data and send it
to one or more recipients. With the public keys of the recipients, a
user may encrypt the data so that only the intended recipients can
decrypt and read the it. This specification separates these two
services so that an originator may apply either or both, in either
order.
The name forms and identifiers are described in detail in the next
section. Succeeding sections specify how PEM and MIME are used together
and other ancillary details.
4. Name Forms and Identifiers
Currently, [3] requires the use of certificates to identify the public
key (and corresponding private key) used to create a PEM message.
Within certificates, [4] requires the use of distinguished names as
specified by the X.500 Series of Recommendations. However, the Internet
community has a great deal more experience with the use of electronic
mail addresses as a name form and there is a desire to be able to use
arbitrary strings to identify the owners of public keys. Hence, there
is a need to support name forms which do not conform to the expected
usage of distinguished names.
When processing PEM messages it is necessary to be able to uniquely
identify the key pair used to create the message. A certificate is
uniquely identified by the combination of its issuer's distinguished
name and its serial number. Thus, the issuer name and serial number
uniquely identifies a key pair. Since a user may have more than one key
pair, a name form is insufficient for this purpose. An identifier is
required that consists of both a name form and key identifier, a value
assigned to a key pair by its owner.
In addition, users may distribute their public keys via mechanisms
outside the scope of the PEM specification, for example, in a file via
FTP. As a result, it is desirable to be able to explicitly specify the
public key used rather than an identifier of the public key. A
significant benefit of this mechanism is the ability to support
encrypted, anonymously signed mail.
The objective of the various Originator and Recipient fields specified
in [3] is to identify which public key has been used or is required.
This document simplifies the set of fields by specifying exactly two:
Originator-ID: for originators and Recipient-ID: for recipients. This
specification defines six (6) identifiers with which the public key used
may be indicated in each of these fields.
In the next section the 3 name forms are described in detail. Following
that is the specification of the 6 identifiers.
4.1. Name Forms
There are 3 name forms specified by this document: email address,
distinguished names, and arbitrary strings.
4.1.1. Email Addresses
The email address (grammar token <emailstr>) used must be a valid RFC822
address, which is defined in terms of the two grammar tokens <addr-spec>
and <route-addr>. The grammar for these two tokens is included in the
Appendix as a convenience; the definitive source for these tokens is
necessarily RFC822 [1].
<emailstr> ::= <addr-spec> / <route-addr>
; an electronic mail address as defined by
; these two tokens from RFC822
For example, the string "galvin@tis.com" is an email address.
4.1.2. Arbitrary Strings
The arbitrary string (grammar token <string>) must chosen from the us-
ascii character set and must have a length of at least 1. It is
possible to encode the actual string in such a way that only characters
from the us-ascii character set are generated, but there is no mechanism
for conveying to a recipient the encoding that was used.
<string> ::= ; a non-null sequence of us-ascii characters
For example, the string
Jim "the SAAG mailing list maintainer" Galvin
is an arbitrary string.
4.1.3. Distinguished Names
The distinguished name (grammar token <dname>) must be constructed
according to the guidelines of the X.500 Directory. For the purposes of
conveying a distinguished name from an originator to a recipient, it
must be ASN.1 encoded and then printably encoded according to the base64
encoding defined by MIME.
<dnamestr> ::= <encbin>
; a printably encoded, ASN.1 encoded
; distinguished name
** EXAMPLE DISTINGUISHED NAME **
4.2. Identifiers
There are 6 identifiers specified by this document: email address,
arbitrary string, distinguished name, PGP key identifier, the public key
itself, and the issuer name and serial number pair from a certificate.
All of these have approximately the same structure as follows:
TYPE, KEYID, STRING
The TYPE field is a literal string, one for each of the possible
identifiers.
The KEYID field is used to distinguish between the multiple public keys
that may be associated with the name form in the STRING field. In 3 of
the identifiers its value is arbitrary, chosen by the owner of the key
pair, except that it must be distinct from all the other KEYIDs used by
the owner. Suggested values include a portion (low-order 16 or 32 bits)
or all of the actual public key used. In the other 3 identifiers the
value is still chosen by the owner of the public key and it must still
be unique, but its value is chosen from a more restricted alphabet.
The STRING field is the name form and has a different syntax according
to the value of the TYPE field.
The identifier used in each of the originator and recipient fields is
described by the following grammar. The definition of the key
identifier token is included here since it used by several of the
identifiers below.
<id> ::= <nameid> / <id-publickey> / <id-issuer>
<nameid> ::= <id-email> / <id-string> / <id-dname> / <id-pgp>
<keyid> ::= <encbin>
; a printably encoded non-null sequence of octets
Each of the identifier name forms is described below.
4.2.1. Email Address
The email address identifier has the following syntax.
<id-email> ::= "EN" "," <keyid> "," <emailstr> CRLF
4.2.2. Arbitrary String
The arbitrary string identifier has the following syntax.
<id-string> ::= "STR" "," <keyid> "," <string> CRLF
4.2.3. Distinguished Name
The distinguished name identifier has the following syntax.
<id-dname> ::= "DN" "," <keyid> "," <dnamestr> CRLF
The actual form and syntax of the distinguished name is outside the
scope of this specification. RFC1422 specifies one possible form based
on a particular choice of a certification hierarchy for certificates.
4.2.4. PGP Public Key
The PGP public key identifier has the following syntax.
<id-pgp> ::= "PGP2" ",0x" <pgp-keyid> "," <string> CRLF
<pgp-keyid> ::= ; a sequence from the following alphabet: {0-9, A-F}
; which is either exactly six or eight characters long
4.2.5. Public Key
The public key identifier has the following syntax. This identifer, as
compared to the others, has the unique property that the STRING element
is optional and, when included, is not a string but rather one of four
of the other identifiers.
<id-publickey> ::= "PK" "," <publickey> [ "," <nameid> ] CRLF
<publickey> ::= <encbin>
; a printably encoded, ASN.1 encoded
; subjectPublicKeyInfo
In normal usage, the STRING element is expected to be absent. When
present, it represents a mechanism by which an identifier (name form and
key identifier) can be associated with a public key. Recipients of a
public key identifier must take care to verify the accuracy of the
purported association. If not, it may be possible for a malicious
originator to assert an identifier that accords the originator
unauthorized privileges. See Section 7.2 for more details.
The object subjectPublicKeyInfo is imported from the X.500 Directory
from the certificate object. It is currently the best choice for a
general purpose public key encoding.
4.2.6. Issuer Name and Serial Number
The issuer name and serial number identifier has the following syntax.
<id-issuer> ::= "IS" "," <dnamestr> "," <serial> CRLF
<serial> ::= 1*<hexchar>
; hex dump of the serial number of a certificate
The <id-issuer> identifier is included for backward compatibility with
the ID-ASymmetric fields defined in [3]. The older fields are easily
converted to this new form by prefixing the old value with "IS," and
replacing the field name with an appropriate new ID field.
5. Applying PEM Security Services to MIME Body Parts
The next section describes the processing steps necessary to prepare a The next section describes the processing steps necessary to prepare a
MIME body part for the application of PEM security services. The MIME body part for the application of PEM security services. The
succeeding two sections describe the content of the multipart/signed and succeeding two sections describe the content of the multipart/signed and
multipart/encrypted body parts resulting from the application of PEM multipart/encrypted body parts resulting from the application of PEM
security services to MIME body parts. security services to MIME body parts.
3.1. PEM Processing Steps 5.1. PEM Processing Steps
The following three steps describe the preparation of outbound PEM
messages. These steps may be repeated as necessary to prepare a message
for submission.
(1) Local Form -- the content of the message is prepared in the native
format of the user's local environment
(2) Canonical Form -- the content of the message is transformed to a
canonical form for the digital signature service; no
canonicalization is required for the encryption service
(3) Security Form -- either of the signature or encryption services may
be applied
Each of these steps is described in detail below. Their relationship to The definition of the multipart/signed and multipart/encrypted body
message composition and delivery is described in Section ??. parts in [7] specifies three steps for creating both body parts.
3.1.1. Step 1: Local Form (1) The body part is to be protected is created according to a local
convention.
The message content is created in the native format of the user's local (2) The body part is prepared for protection according to the protocol
environment. parameter.
3.1.2. Step 2: Canonical Form (3) The prepared body part is protected according to the protocol
parameter.
Prior to the application of the digital signature service, the content This specification makes no changes to step one in the sequence. For
must be in a canonical form. No canonicalization is required for the step two, there is no preparation necessary for the encryption service.
encryption service and therefore processing continues with the next For the digital signature service, the body part must be canonicalized
step. as described below. This specification makes no changes to step three
in the sequence.
Transforming the content to be signed into a canonical form is a Prior to the application of the digital signature service, the body part
necessary and essential step in the digital signature process. The must be in a canonical form. Transforming the body part to be signed
canonical form must satisfy the property that it is uniquely and into a canonical form is a necessary and essential step in the digital
unambiguously representable on both the originator and recipient's local signature process. The canonical form must satisfy the property that it
environment. This is required in order to ensure that both the is uniquely and unambiguously representable in both the originator and
originator and recipient have the same data with which to calculate the recipient's local environment. This is required in order to ensure that
digital signature; the originator needs to be able to include the both the originator and recipient have the same data with which to
digital signature value when transferring the body part, while the calculate the digital signature; the originator needs to be able to
recipient needs to be able to compare a re-calculated value with the include the digital signature value when transferring the body part,
received value. Further, the canonical form should satisfy the property while the recipient needs to be able to compare a re-computed value with
that it is representable on as many different host computers as the received value. Further, the canonical form should satisfy the
property that it is representable on as many different host computers as
possible. By satisfying this property, signed data may be forwarded by possible. By satisfying this property, signed data may be forwarded by
recipients to additional recipients, who will also be able to verify the recipients to additional recipients, who will also be able to verify the
original signature. This service is called forwardable authentication. original signature. This service is called forwardable authentication.
The canonical form of all content types is defined to be 7bit. The data The canonicalization transformation is a two step process. First, the
to be signed must be represented as 7bit. Since the MIME standard body part must be converted to canonical representation suitable for
explicitly disallows nested encodings, the body parts enclosed in a transport between originators and recipients. Second, the body part
multipart content type, for example, must be encoded in a 7bit must have its line delimiters canonicalized prior to computing the
digital signature and prior to each verification of the digital
signature.
The canonical representation of all body parts is specified to be 7bit,
as defined by [2]. Since the headers of body parts are already required
to be representable in 7bit, this step requires that if the data to be
signed is not already 7bit it must be encoded with an appropriate MIME
content transfer encoding. Note, since the MIME standard explicitly
disallows nested content transfer encodings, i.e., the content types
multipart and message may not themselves be encoded, body parts enclosed
within, for example, a multipart content type, must be encoded in a 7bit
representation. Any valid MIME encoding may be selected. representation. Any valid MIME encoding may be selected.
The 7bit representation of the data is transferred to the recipient. As The 7bit representation of the data must be transferred to the
may be required by MIME, an appropriate Content-Transfer-Encoding: recipient. As may be required by MIME, an appropriate Content-
header is included with the data. Upon receipt, a MIME implementation Transfer-Encoding: header is included with the data. Upon receipt, a
would verify the signature of the data prior to decoding the data and MIME implementation would verify the signature of the data prior to
displaying it to the recipient. decoding the data and displaying it to the recipient.
Representing all complex content types as 7bit transforms them into Representing all complex content types as 7bit transforms them into
text-based content types. However, text-based content types present a text-based content types. However, text-based content types present a
unique problem. In particular, there are far too many broken message unique problem. In particular, the line delimiter used on a text-based
transfer agents that make arbitrary changes to text-based messages as content type is specific to a local environment; different environments
they are relayed, including adding, deleting, or changing TAB and SPACE use the single character carriage-return (<CR>), the single character
characters, and line delimiters are altered by message transfer agent line-feed (<LF>), or the two character sequence "carriage-return line-
protocols. These changes will make it impossible for recipients to
verify the signature on a message. feed (<CR><LF>)."
The application of the digital signature service requires that the same The application of the digital signature service requires that the same
line delimiter be used by both the originator and the recipient. This line delimiter be used by both the originator and the recipient. This
document specifies that the two character sequence "<CR><LF>" must be document specifies that the two character sequence "<CR><LF>" must be
used as the line delimiter. Thus, the canonicalization transformation used as the line delimiter. Thus, the canonicalization transformation
is to transform the local line delimiter to the two character sequence includes the transformation of the local line delimiter to the two
"<CR><LF>". character sequence "<CR><LF>".
The transformation to the universal line delimiter is only required for The transformation to the canonical line delimiter is only required for
the purposes of computing the digital signature. Thus, originators must the purposes of computing the digital signature. Thus, originators must
apply the universal line delimiter transformation before calculating the apply the canonical line delimiter transformation before computing the
digital signature but must transfer the data without the universal line digital signature but must transfer the data without the canonical line
delimiter transformation. Similarly, recipients must apply the delimiter transformation. Similarly, recipients must apply the
universal line delimiter transformation before calculating the digital canonical line delimiter transformation before computing the digital
signature. signature.
NOTE: An originator can not transfer the content with the NOTE: An originator can not transfer the content with the
universal line delimiter transformation intact because the canonical line delimiter transformation intact because the
transformation process is not idempotent. In particular, SMTP transformation process is not idempotent. In particular, SMTP
servers may themselves convert the universal line delimiter to a servers may themselves convert the canonical line delimiter to a
local line delimiter, prior to the message being delivered to local line delimiter, prior to the message being delivered to
the user. Thus, a recipient has no way of knowing if the the user. Thus, a recipient has no way of knowing if the
transformation is present or not. Thus, if the recipient transformation is present or not. Thus, if the recipient
applies the transformation to a content in which it is already applies the transformation to a content in which it is already
present, the resulting content may have two line delimiters present, the resulting content may have two line delimiters
present, which would cause the verification of the signature to present, which would cause the verification of the signature to
fail. fail.
3.1.3. Step 3: Security Form IMPLEMENTORS NOTE: Implementors should be aware that the
transformation to a canonical representation is a function that
Either of the digital signature or encryption services is applied to a is available even in a minimally compliant MIME user agent.
content. The content to be protected is prepared by a MIME Further, the canonical line delimiter transformation required
implementation and made available to a PEM implementation according to a here is distinct from the same transformation included in that
local convention. The PEM implementation must produce two outputs: the function. Specifically, the line delimiter transformation in
data that has been protected and the control information necessary to the former case is performed prior to the application of the
verify or remove the protection. These outputs must be made available canonical representation while it is performed after the
to the MIME implementation which will construct a multipart/signed or application of the canonical representation in the latter case.
multipart/encrypted content, according to the service requested. The
multipart content replaces the content that was selected for protection.
3.2. Use of multipart/signed Content Type 5.2. Use of multipart/signed Content Type
When this content type is used, the value of the required parameter When this content type is used, the value of the required parameter
"protocol" is "pem" and the value of the required parameter "hashalg" is "protocol" is "pem" and the value of the required parameter "hashalg" is
one of the valid choices from [5], for example: one of the valid choices from [5], for example:
Content-Type: multipart/signed; protocol="pem"; hashalg="md5"; Content-Type: multipart/signed; protocol="pem"; hashalg="md5";
boundary="Signed Message" boundary="Signed Message"
--Signed Message --Signed Message
Content-Type: text/plain Content-Type: text/plain
This is some example text. This is some example text.
skipping to change at page 6, line 13 skipping to change at page 11, line 31
where the <pemsig> token is defined as follows. where the <pemsig> token is defined as follows.
<pemsig> ::= <version> (1*<origasymflds>) <pemsig> ::= <version> (1*<origasymflds>)
<version> ::= "Version:" "5" CRLF <version> ::= "Version:" "5" CRLF
<origasymflds> ::= <origid> <micinfo> <origasymflds> ::= <origid> <micinfo>
<origid> ::= "Originator-ID:" <id> CRLF <origid> ::= "Originator-ID:" <id> CRLF
The token <id> is defined in Section ??. The token <id> is defined in Section 4.2.
The only valid value for a Content-Transfer-Encoding: header, if The only valid value for a Content-Transfer-Encoding: header, if
included, is "7bit". included, is "7bit".
3.3. Use of multipart/encrypted Content Type 5.3. Use of multipart/encrypted Content Type
When this content type is used, the value of the required parameter When this content type is used, the value of the required parameter
"protocol" is "pem", for example: "protocol" is "pem", for example:
Content-Type: multipart/encrypted; protocol="pem"; Content-Type: multipart/encrypted; protocol="pem";
boundary="Encrypted Message" boundary="Encrypted Message"
--Encrypted Message --Encrypted Message
Content-Type: application/keys Content-Type: application/keys
skipping to change at page 7, line 5 skipping to change at page 12, line 31
<pemkeys> ::= <version> <dekinfo> 1*<recipasymflds> <pemkeys> ::= <version> <dekinfo> 1*<recipasymflds>
<version> ::= "Version:" "5" CRLF <version> ::= "Version:" "5" CRLF
<recipasymflds> ::= <recipid> <asymkeyinfo> <recipasymflds> ::= <recipid> <asymkeyinfo>
<recipid> ::= "Recipient-ID:" <id> CRLF <recipid> ::= "Recipient-ID:" <id> CRLF
<asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek> CRLF <asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek> CRLF
The token <id> is defined in Section ??. The token <id> is defined in Section 4.2.
4. Removing PEM Security Services from PEM Body Parts
Upon receipt of a multipart/signed or multipart/encrypted body part, the
PEM security services are removed by reversing the sequence of steps
specified in Section ??, modifying step 2 as follows.
(1) All content types must have their line delimiters canonicalized
prior to removing the PEM security services.
(2) Outer layers of PEM security services must be processed prior to
processing inner layers of PEM security services. Processing
includes a user choosing to display a content without removing the
PEM security services.
5. Definition of New Name Forms
WARNING: This is the first draft of this section. Although
conceptually it represents a direction that will not change,
while this document is an internet draft the details of the
specification are subject to change at any time, without notice,
owing to comments and implementation experience. Implementors
are encouraged to contact the authors for the current status.
Currently, [3] requires the use of certificates to specify the public
key used to create a PEM message. Within certificates, [4] requires the
use of distinguished names as specified by the X.500 Series of
Recommendations. However, the Internet community has a great deal more
experience with the use of electronic mail addresses as identifiers and
there is a desire to be able to use arbitrary strings to identify the
owners of public keys. Hence, there is a need to support name forms
which do not conform to the expected usage of distinguished names.
In addition, users may distribute their public keys via mechanisms
outside the scope of the PEM specification, for example, in a file via
FTP as opposed to in a certificate. As a result, it is desirable to be
able to explicitly specify the public key used rather than an identifier
of the public key.
The objective of the various Originator and Recipient fields specified
in [3] is to indicate which public key has been used or is required.
This document simplifies the set of fields by specifying exactly two:
Originator-ID: for originators and Recipient-ID: for recipients. The
value of each of these fields is indicated by the token <id>, which is
defined as follows.
<id> ::= <id-email> / <id-string> / <id-dname>
/ <id-publickey> / <id-issuer>
<id-email> ::= "EN" "," <atstring> 6. Removing PEM Security Services from PEM Body Parts
"," <hashalgid> "," <hashpublickey>
<id-string> ::= "STR" "," <string>
"," <hashalgid> "," <hashpublickey>
<id-dname> ::= "DN" "," <dname>
"," <hashalgid> "," <hashpublickey>
<id-publickey> ::= "PK" ","
"," <pkalgid> "," <publickey>
"," ( <string> / <atstring> )
<id-issuer> ::= "IS" "," <dname> "," <serial>
<atstring> ::= <encbin> This section describes the processing steps necessary to verify or
; a printably encoded, ASN.1 encoded decrypt the PEM security services that have been applied to MIME body
; string containing exactly one '@' parts. Outer layers of PEM security services must be processed prior to
<string> ::= <encbin> processing inner layers of PEM security services. Processing includes a
; "a sequence of characters excluding '@'" user choosing to display a content without removing the PEM security
; a printably encoded, ASN.1 value services.
<hashalgid> ::= "to be defined by RFC 1423" The definition of the multipart/signed and multipart/encrypted body
<hashpublickey> ::= 1*<hexchar> parts in [7] specifies three steps for receiving both body parts.
; hex dump of the <hashalgid> hash of the
; public key
<pkalgid> ::= "to be defined by RFC 1423" (1) The protected body part and the control information body part are
<publickey> ::= <encbin> prepared for processing.
; a printably encoded, ASN.1 encoded public key
<dname> ::= <encbin> (2) The prepared body parts are made available to the protection
; a printably encoded, ASN.1 encoded removal process.
; distinguished name
<serial> ::= 1*<hexchar>
; hex dump of the serial number of a certificate
The inclusion of the hash of the public key is intended to facilitate (3) The results of the protection removal process are made available to
the recognition of which public key among several that may be associated the user and processing continues with the unprotected body part,
with the string or distinguished name. as returned by the protection removal process.
The identifiers <id-email> and <id-string> are distinguished only by the For step one, the preparation for digitally signed and encrypted body
presence or absence of the character '@'. In all other respects they parts is different, as described below. No changes are required to
are equivalent and are encoded strings that are to be used as the steps two and three in the sequence.
subject name in a certificate. This distinguishing characteristic was
chosen as opposed to defining a new object identifier to represent email
addresses because of the perceived difficulty in distributing and
implementing the definition of a new object identifier.
The <id-publickey> identifier allows for the direct distribution and For multipart/signed body parts, the control information is prepared by
indication of the public key that was or is to be used to process the removing any content transfer encodings that may be present. The
message. digitally signed body part is prepared by leaving the content transfer
encodings intact and canonicalizing the line delimiters according to
Step 2 of Section 5.1.
The <id-issuer> identifier is included for backward compatibility with Multipart/encrypted body parts are prepared by removing the content
the ID-ASymmetric fields defined in [3]. The older fields are easily transfer encodings, if present, from both the control information and
converted to this new form by prefixing the old value with "IS," and the encrypted body part.
replacing the field name with an appropriate new ID field.
6. Definition of New Content Types 7. Definition of New Content Types
This document defines two new content types, the contents of which This document defines two new content types, the contents of which
comprise a replacement mechanism for [6]. The first content type is comprise a replacement mechanism for [6]. The first content type is
application/key-request, which replaces the certification and CRL- application/key-request, which replaces the certification and CRL-
retrieval request messages. The second content type is retrieval request messages. The second content type is
application/key-data, which replaces the certification reply message, application/key-data, which replaces the certification reply message,
the crl-storage request message, and the crl-retrieval 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 There were no requirements for a crl-storage reply message and none are
specified in this document. This document includes a specification for specified in this document. This document includes a specification for
a certificate request message, which was previously undefined. a public key and certificate request message, which were previously
undefined.
NOTE: RFC1424 has some descriptive text, especially for NOTE: RFC1424 has some descriptive text, especially for
certification messages, that should probably be included. certification messages, that should probably be included.
6.1. application/key-request Content Type Definition 7.1. application/key-request Content Type Definition
(1) MIME type name: application (1) MIME type name: application
(2) MIME subtype name: key-request (2) MIME subtype name: key-request
(3) Required parameters: none (3) Required parameters: none
(4) Optional parameters: none (4) Optional parameters: none
(5) Encoding considerations: quoted-printable is always sufficient (5) Encoding considerations: quoted-printable is always sufficient
skipping to change at page 10, line 27 skipping to change at page 14, line 33
in [6]. The information in the body part is entirely independent of any in [6]. The information in the body part is entirely independent of any
other body part. As such, the application/key-request content type is other body part. As such, the application/key-request content type is
an independent body part. an independent body part.
The certification request, certificate-retrieval request and crl- The certification request, certificate-retrieval request and crl-
retrieval request are provided for directly. If the content contains a retrieval request are provided for directly. If the content contains a
Certification: field it requests certification of the self-signed Certification: field it requests certification of the self-signed
certificate in the field value. If the content contains an Issuer: certificate in the field value. If the content contains an Issuer:
field it requests the certificate revocation list chain beginning with field it requests the certificate revocation list chain beginning with
the issuer identified in the field value. If the content contains a the issuer identified in the field value. If the content contains a
Subject: field it requests the certificate chain beginning with the Subject: field it requests either the public key of the subject or the
subject identified in the field value. certificate chain beginning with the subject identified in the field
value, or both.
The Subject: and Issuer: fields each contain a value of type Name, The Subject: and Issuer: fields each contain a value of type <id>, which
encoded according to the Basic Encoding Rules, then in ASCII, as for the is defined in Section 4.2.
Originator-ID-Asymmetric: field of [3].
The crl-storage request is provided for by the application/key-data The crl-storage request is provided for by the application/key-data
content type described in the next section. content type described in the next section.
In each case, the response is transmitted in an application/key-data In each case, the response is transmitted in an application/key-data
content type. When returning certificate and certificate revocation content type. When returning public keys, certificate chains, and
list chains, if there exists more than one chain, several certificate revocation list chains, if there exists more than one,
application/key-data contents are to be returned in the reply message, several application/key-data contents are to be returned in the reply
one for each chain.
6.2. application/key-data Content Type Definition message, one for each.
7.2. application/key-data Content Type Definition
The principal objective of this content type is to convey cryptographic
keying material from an originator to a recipient. However, no explicit
provision is made for determining the authenticity or accuracy of the
data being conveyed. In particular, when a public key and the
identifier for its owner is conveyed, there is nothing to prevent an
originator or any interloper along the path from an originator to a
recipient from substituting alternate values for either the public key
or the identifier, thus setting up the recipient to potentially send
sensitive information that may be intercepted and disclosed
inappropriately.
It is incumbent upon a recipient to verify the authenticity and accuracy
of the data received prior to its use. The problem is addressed by the
use of certificates, since a certification hierarchy is a well-defined
mechanism that conveniently supports the automatic verification of the
data. Alternatively, the application/key-data body part could be
digitally signed by the originator. In this way, if a recipient
believes that correct originator's public key is available locally and
if the recipient believes the originator would convey accurate data,
then the key data received from the originator can be believed.
NOTE: Insofar as a certificate represents a mechanism by which
an issuer vouches for the binding between the name and public
key it embodies, the signing of an application/key-data body
part is a similar mechanism.
(1) MIME type name: application (1) MIME type name: application
(2) MIME subtype name: key-data (2) MIME subtype name: key-data
(3) Required parameters: none (3) Required parameters: none
(4) Optional parameters: none (4) Optional parameters: none
(5) Encoding considerations: quoted-printable is always sufficient. (5) Encoding considerations: quoted-printable is always sufficient.
(6) Security Considerations: none (6) Security Considerations: none
The content of this body part corresponds to the following production. The content of this body part corresponds to the following production.
<certdata> ::= <certchain> / <crlchain> <certdata> ::= <version>
<certchain> ::= <version> <cert> *( [ <crl> ] <cert> ) ( <keydata> / <certchain> / <crlchain> )
<crlchain> ::= <version> 1*( <crl> [ <cert> ] ) <version> ::= "Version:" "5" CRLF
<keydata> ::= "Key:" <id> "," <nameid> CRLF
<certchain> ::= <cert> *( [ <crl> ] <cert> )
<crlchain> ::= 1*( <crl> [ <cert> ] )
<cert> ::= "Certificate:" <encbin> CRLF <cert> ::= "Certificate:" <encbin> CRLF
<crl> ::= "CRL:" <encbin> CRLF <crl> ::= "CRL:" <encbin> CRLF
<version> ::= "Version:" "5" CRLF
This content type is used to transfer certificate or Certificate This content type is used to transfer public keys, certificate chains,
Revocation List (CRL) information. The information in the body part is or Certificate Revocation List (CRL) chains. The information in the
entirely independent of any particular privacy enhanced message. (Note body part is entirely independent of any other body part. (Note that
that the converse is not true: the validity of a privacy enhanced the converse is not true: the validity of a protected body part cannot
message cannot be determined without the proper certificates or current be determined without the proper public keys, certificates, or current
CRL information.) As such, the application/key-data content type is an CRL information.) As such, the application/key-data content type is an
independent body part. independent body part.
The <keydata> production contains exactly one public key. It is used to
bind a public key with its corresponding name form and key identifier.
It is recommended that when responders are returning this information
that the enclosing body part be digitally signed by the responder in
order to protect the information.
The <certchain> production contains one certificate chain. A The <certchain> production contains one certificate chain. A
certificate chain starts with a certificate and continues with the certificate chain starts with a certificate and continues with the
certificates of subsequent issuers. Each issuer certificate included certificates of subsequent issuers. Each issuer certificate included
must have issued the preceding certificate. For each issuer, a CRL may must have issued the preceding certificate. For each issuer, a CRL may
be supplied. A CRL in the chain belongs to the immediately following be supplied. A CRL in the chain belongs to the immediately following
issuer. Therefore, it potentially contains the immediately preceding issuer. Therefore, it potentially contains the immediately preceding
certificate. certificate.
The <crlchain> production contains one certificate revocation list The <crlchain> production contains one certificate revocation list
chain. The CRLs in the chain begin with the requested CRL and continue 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 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 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 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 chain must belong to the issuer of the immediately preceding CRL.
The relationship between a certificate and an 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 is the same in both <certchain> and <crlchain>. In a <certchain> the
a <crlchain> the certificates are optional. CRLs are optional. In a <crlchain> the certificates are optional.
7. 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
the requested type of security enhancement as well as tampering with the
enhancement request itself.
7.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 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/signed or multipart/encrypted. The new body part
contains two body parts, whose content depends on the enhancement
requested, which are constructed according to the specifications in
this document.
(5) This multipart content replaces the original object.
7.2. Post-Delivery Algorithm
When a user receives a message containing a multipart 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 content 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.
8. Examples 8. Examples
NOTE: To be included upon completion of implementation. NOTE: To be included upon completion of implementation.
9. Observations 9. Observations
The use of the pre-submission and post-delivery algorithms to combine The use of the pre-submission and post-delivery algorithms to combine
PEM and MIME capabilities exhibits several properties: PEM and MIME capabilities exhibits several properties:
skipping to change at page 14, line 26 skipping to change at page 17, line 30
(3) It provides for messages containing several privacy enhanced (3) It provides for messages containing several privacy enhanced
contents, thereby removing the requirement for PEM software to be contents, thereby removing the requirement for PEM software to be
able to generate or interpret a single content which intermixes able to generate or interpret a single content which intermixes
both unenhanced and enhanced components. both unenhanced and enhanced components.
The use of a MIME-capable user agent makes complex nesting of enhanced The use of a MIME-capable user agent makes complex nesting of enhanced
message body parts much easier. For example, the user can separately message body parts much easier. For example, the user can separately
sign and encrypt a message. This motivates a complete separation of the sign and encrypt a message. This motivates a complete separation of the
confidentiality security service from the digital signature security confidentiality security service from the digital signature security
service. That is, different keys could be used for the different service. That is, different key pairs could be used for the different
services and could be protected separately. In the asymmetric case, services and could be protected separately. This means an employee's
this means an employee's company could be given access to the (private) company could be given access to the (private) decryption key but not
decryption key but not the (private) signature key, thereby granting the the (private) signature key, thereby granting the company the ability to
company the ability to decrypt messages addressed to the employee in decrypt messages addressed to the employee in emergencies without also
emergencies without also granting the company the ability to sign granting the company the ability to sign messages as the employee.
messages as the employee.
The use of two private keys requires the ability to maintain multiple The use of two private keys requires the ability to maintain multiple
certificates for each user. certificates for each user.
10. Summary of Changes to PEM Specification 10. Summary of Changes to PEM Specification
This document updates the message encryption and signature procedures This document updates the message encryption and signature procedures
defined by [3] and obsoletes the key certification and related services defined by [3] and obsoletes the key certification and related services
defined by [6]. The changes are enumerated below. defined by [6]. The changes are enumerated below.
skipping to change at page 15, line 10 skipping to change at page 18, line 12
be applied only to message bodies that have been signed. By be applied only to message bodies that have been signed. By
providing for each of the services separately, they may be applied providing for each of the services separately, they may be applied
recursively in any order according to the needs of the requesting recursively in any order according to the needs of the requesting
application. application.
(2) PEM implementations are currently restricted to processing only (2) PEM implementations are currently restricted to processing only
text-based electronic mail messages. In fact, the message text is text-based electronic mail messages. In fact, the message text is
required to be represented by the ASCII character set with required to be represented by the ASCII character set with
"<CR><LF>" line delimiters. This restriction no longer applies. "<CR><LF>" line delimiters. This restriction no longer applies.
(3) With the removal of the text restriction it is not possible to (3) MIME includes transfer encoding operations to ensure the unmodified
specify a universal canonical form. However, canonicalization is
required for the digital signature service, so 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
transfer of body parts, which obviates these services in PEM. transfer of body parts, which obviates these services in PEM.
(5) PEM specifies a Proc-Type: header field to identify the type of (4) PEM specifies a Proc-Type: header field to identify the type of
processing that was performed on the message. This functionality processing that was performed on the message. This functionality
is subsumed by the MIME Content-Type: headers. The Proc-Type: is subsumed by the MIME Content-Type: headers. The Proc-Type:
header also included a decimal number that was used to distinguish header also included a decimal number that was used to distinguish
among incompatible encapsulated header field interpretations which among incompatible encapsulated header field interpretations which
may arise as changes are made to the PEM standard. This may arise as changes are made to the PEM standard. This
functionality is replaced by the Version: header specified in this functionality is replaced by the Version: header specified in this
document. document.
(6) PEM specifies a Content-Domain: header, the purpose of which is to (5) PEM specifies a Content-Domain: header, the purpose of which is to
describe the type of the content which is represented within a PEM describe the type of the content which is represented within a PEM
message's encapsulated text. This functionality is subsumed by the message's encapsulated text. This functionality is subsumed by the
MIME Content-Type: headers. MIME Content-Type: headers.
(7) The PEM specifications include a document that defines new types of (6) The PEM specifications include a document that defines new types of
PEM messages, specified by unique values used in the Proc-Type: PEM messages, specified by unique values used in the Proc-Type:
header, to be used to request certificate and certificate header, to be used to request certificate and certificate
revocation list information. This functionality is subsumed by two revocation list information. This functionality is subsumed by two
new content types specified in this document. new content types specified in this document.
(8) The header fields having to do with certificates (Originator- (7) The header fields having to do with certificates (Originator-
Certificate: and Issuer-Certificate:) and CRLs (CRL:) are relegated Certificate: and Issuer-Certificate:) and CRLs (CRL:) are relegated
for use only in the application/key-data and application/key- for use only in the application/key-data and application/key-
request content types and are no longer allowed in the header request content types and are no longer allowed in the header
portion of a PEM signed or encrypted message. portion of a PEM signed or encrypted message.
(9) The grammar specified here explicitly separates the header fields (8) The grammar specified here explicitly separates the header fields
that may appear for the encryption and signature security services. that may appear for the encryption and signature security services.
It is the intent of this document to specify a precise expression It is the intent of this document to specify a precise expression
of the allowed header fields; there is no intent to reduce the of the allowed header fields; there is no intent to reduce the
functionality of combinations of encryption and signature security functionality of combinations of encryption and signature security
from those of [3]. from those of [3].
(10) With the separation of the encryption and signature security (9) With the separation of the encryption and signature security
services, there is no need for a MIC-Info: field in the headers services, there is no need for a MIC-Info: field in the headers
associated with an encrypted message under asymmetric key associated with an encrypted message.
management.
(11) In [3], when asymmetric key management is used, an Originator-ID (10) In [3], when asymmetric key management is used, an Originator-ID
field is required in order to identify the private key used to sign 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: the MIC argument in the MIC-Info: field. Because no MIC-Info:
field is associated with the encryption security service under field is associated with the encryption security service under
asymmetric key managment, there is no requirement in that case to asymmetric key managment, there is no requirement in that case to
include an Originator-ID field. include an Originator-ID field.
These changes represent a departure in mechanism, not in effect, from These changes represent a departure in mechanism, not in effect, from
those specified in [3] and [6]. The following technical changes to [3] those specified in [3] and [6]. The following technical changes to [3]
and [4] are also specified by this document. and [4] are also specified by this document.
(1) The grammar specified here explicitly excludes symmetric key (1) The grammar specified here explicitly excludes symmetric key
management. Currently, there are no generally available management. Currently, there are no generally available
implementations of symmetric key management nor are there any known implementations of symmetric key management nor are there any known
plans for implementing it. As a result, the IETF standards process plans for implementing it. As a result, the IETF standards process
will require this feature to be dropped when the documents are will require this feature to be dropped when the documents are
promoted to draft standard status from proposed standard status. promoted to draft standard status from proposed standard status.
(2) This document requires all data that is to be digitally signed to (2) This document requires all data that is to be digitally signed to
be represented in 7bit form. be represented in 7bit form.
(3) This document relaxes the syntax of distinguished names. In (3) This document broadens the allowable name forms that users may use
particular, distinguished names are not constrained to conform to to identify their public keys. Users may use arbitrary strings and
the X.500 Series of Recommendations. Instead users may use email addresses as their name. Further, users may distribute their
arbitrary strings and email addresses as their name. Further, public key directly in lieu of using certificates. In support of
users may distribute their public key directly in lieu of using this change the Originator-ID-ASymmetric: and Recipient-ID-
certificates. In support of this change the Originator-ID- ASymmetric: fields are deprecated in favor of Originator-ID: and
ASymmetric: and Recipient-ID-ASymmetric: fields are deprecated in Recipient-ID: fields, respectively.
favor of Originator-ID: and Recipient-ID: fields, respectively.
11. Collected Grammar 11. Collected Grammar
The following is a summary of the grammar presented in this document. The following is a summary of the grammar presented in this document.
(1) Signature headers (1) Signature headers
<pemsig> ::= <version> (1*<origasymflds>) <pemsig> ::= <version> (1*<origasymflds>)
<version> ::= "Version:" "5" CRLF <version> ::= "Version:" "5" CRLF
skipping to change at page 17, line 24 skipping to change at page 20, line 24
<pemkeys> ::= <version> <dekinfo> 1*<recipasymflds> <pemkeys> ::= <version> <dekinfo> 1*<recipasymflds>
<version> ::= "Version:" "5" CRLF <version> ::= "Version:" "5" CRLF
<recipasymflds> ::= <recipid> <asymkeyinfo> <recipasymflds> ::= <recipid> <asymkeyinfo>
<recipid> ::= "Recipient-ID:" <id> CRLF <recipid> ::= "Recipient-ID:" <id> CRLF
<asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek> CRLF <asymkeyinfo> ::= "Key-Info" ":" <ikalgid> "," <asymencdek> CRLF
(3) Request Headers (certificate, certification, etc.) (3) Identifier Name Forms
<id> ::= <nameid> / <id-publickey> / <id-issuer>
<nameid> ::= <id-email> / <id-string> / <id-dname> / <id-pgp>
<id-email> ::= "EN" "," <keyid> "," <emailstr> CRLF
<id-string> ::= "STR" "," <keyid> "," <string> CRLF
<id-dname> ::= "DN" "," <keyid> "," <dnamestr> CRLF
<id-pgp> ::= "PGP2" ",0x" <pgp-keyid> "," <string> CRLF
<id-publickey> ::= "PK" "," <publickey> [ "," <nameid> ] CRLF
<id-issuer> ::= "IS" "," <dnamestr> "," <serial> CRLF
<keyid> ::= <encbin>
; a printably encoded non-null sequence of octets
<emailstr> ::= <addr-spec> / <route-addr>
; an electronic mail address as defined by
; these two tokens from RFC822
<string> ::= ; a non-null sequence of us-ascii characters
<dnamestr> ::= <encbin>
; a printably encoded, ASN.1 encoded
; distinguished name
<pgp-keyid> ::= ; a sequence from the following alphabet: {0-9, A-F}
; which is either exactly six or eight characters long
<publickey> ::= <encbin>
; a printably encoded, ASN.1 encoded
; subjectPublicKeyInfo
<serial> ::= 1*<hexchar>
; hex dump of the serial number of a certificate
(4) Request Headers (certificate, certification, etc.)
<request> ::= <version> <request> ::= <version>
( <subject> / <issuer> / <certification> ) ( <subject> / <issuer> / <certification> )
<version> ::= "Version:" "5" CRLF <version> ::= "Version:" "5" CRLF
<subject> ::= "Subject:" <id> CRLF <subject> ::= "Subject:" <id> CRLF
<issuer> ::= "Issuer:" <id> CRLF <issuer> ::= "Issuer:" <id> CRLF
<certification> ::= "Certification:" <encbin> CRLF <certification> ::= "Certification:" <encbin> CRLF
(4) Certificate Headers (certificate, certification revocation list) (5) Data Headers (certificate, certification revocation list)
<certdata> ::= <certchain> / <crlchain> <certdata> ::= <certchain> / <crlchain>
<certchain> ::= <version> <cert> *( [ <crl> ] <cert> ) <certchain> ::= <version> <cert> *( [ <crl> ] <cert> )
<crlchain> ::= <version> 1*( <crl> [ <cert> ] ) <crlchain> ::= <version> 1*( <crl> [ <cert> ] )
<cert> ::= "Certificate:" <encbin> CRLF <cert> ::= "Certificate:" <encbin> CRLF
<crl> ::= "CRL:" <encbin> CRLF <crl> ::= "CRL:" <encbin> CRLF
<version> ::= "Version:" "5" CRLF <version> ::= "Version:" "5" CRLF
12. Security Considerations 12. Security Considerations
skipping to change at page 18, line 40 skipping to change at page 23, line 13
Communications, February 1993. Communications, February 1993.
[5] David M. Balenson. Privacy Enhancement for Internet Electronic [5] David M. Balenson. Privacy Enhancement for Internet Electronic
Mail: Part III: Algorithms, Modes, and Identifiers. RFC 1423, Mail: Part III: Algorithms, Modes, and Identifiers. RFC 1423,
Trusted Information Systems, February 1993. Trusted Information Systems, February 1993.
[6] Burton S. Kaliski. Privacy Enhancement for Internet Electronic [6] Burton S. Kaliski. Privacy Enhancement for Internet Electronic
Mail: Part IV: Key Certification and Related Services. RFC 1424, Mail: Part IV: Key Certification and Related Services. RFC 1424,
RSA Laboratories, February 1993. RSA Laboratories, February 1993.
[7] David Crocker. Multipart/Family Content Types. Work in progress. [7] James Galvin, Sandy Murphy, Steve Crocker, and Ned Freed. Security
Multiparts for MIME: Multipart/Signed and Multipart/Encrypted.
[8] James Galvin. Security Multiparts for MIME: Multipart/Signed and RFC XXXX, Trusted Information Systems and Innosoft, XXXX 1994.
Multipart/Encrypted. Work in progress.
[9] Jon Postel. Simple Mail Transfer Protocol. RFC 821, ISI, August
1982.
15. Authors' Addresses 15. Authors' Addresses
Steve Crocker Steve Crocker
email: crocker@tis.com
James M. Galvin
email: galvin@tis.com
Sandra Murphy
email: murphy@tis.com
Trusted Information Systems Trusted Information Systems
3060 Washington Road 3060 Washington Road
Glenwood, MD 21738 Glenwood, MD 21738
Tel: +1 301 854 6889 Tel: +1 301 854 6889
FAX: +1 301 854 5363 FAX: +1 301 854 5363
email: crocker@tis.com
Ned Freed Ned Freed
Innosoft International, Inc. Innosoft International, Inc.
250 West First Street, Suite 240 250 West First Street, Suite 240
Claremont, CA 91711 Claremont, CA 91711
Tel: +1 909 624 7907 Tel: +1 909 624 7907
FAX: +1 909 621 5319 FAX: +1 909 621 5319
email: ned@innosoft.com email: ned@innosoft.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@tis.com
Sandra Murphy
Trusted Information Systems
3060 Washington Road
Glenwood, MD 21738
Tel: +1 301 854 6889
FAX: +1 301 854 5363
email: murphy@tis.com
16. Appendix: Imported Grammar 16. Appendix: Imported Grammar
The following productions are taken from [3]. The grammar presented in The following productions are taken from [3]. The grammar presented in
[3] remains the authoritative source for these productions; they are [3] remains the authoritative source for these productions; they are
repeated here for the convenience of the reader. repeated here for the convenience of the reader.
<dekinfo> ::= "DEK-Info" ":" <dekalgid> [ "," <dekparameters> ] CRLF <dekinfo> ::= "DEK-Info" ":" <dekalgid> [ "," <dekparameters> ] CRLF
<micinfo> ::= "MIC-Info" ":" <micalgid> "," <ikalgid> "," <micinfo> ::= "MIC-Info" ":" <micalgid> "," <ikalgid> ","
<asymsignmic> CRLF <asymsignmic> CRLF
skipping to change at page 21, line 5 skipping to change at page 24, line 42
<asymsignmic> ::= <RSAsignmic> <asymsignmic> ::= <RSAsignmic>
<RSAsignmic> ::= <encbin> <RSAsignmic> ::= <encbin>
<asymencdek> ::= <RSAencdek> <asymencdek> ::= <RSAencdek>
<RSAencdek> ::= <encbin> <RSAencdek> ::= <encbin>
<hexchar16> ::= 16*16<hexchar> <hexchar16> ::= 16*16<hexchar>
<hexchar> ::= DIGIT / "A" / "B" / "C" / "D" / "E" / "F" <hexchar> ::= DIGIT / "A" / "B" / "C" / "D" / "E" / "F"
; no lower case ; no lower case
The following productions are taken from [1]. The grammar presented in
[1] remains the authorative source for these productions; they are
repeated here for the convenience of the reader.
<addr-spec> ::= <local-part> "@" <domain> ; global address
<local-part> ::= <word> *( "." <word> ) ; uninterpreted
; case-preserved
<domain> ::= <sub-domain> *( "." <sub-domain> )
<sub-domain> ::= <domain-ref> / <domain-literal>
<domain-ref> ::= <atom> ; symbolic reference
<route-addr> ::= "<" [ <route> ] <addr-spec> ">"
<route> ::= 1# ( "@" <domain> ) ":" ; path-relative
<word> ::= <atom> / <quoted-string>
<quoted-string> ::= """ *( <qtext> / <quoted-pair> ) """
<qtext> ::= (any <CHAR> excepting """, "
and including <linear-white-space>)
<quoted-pair> ::= "
<linear-white-space> ::= 1*( [ CRLF ] <LWSP-char> ) ; semantics = SPACE
; CRLF => folding
<LWSP-char> ::= SPACE / HTAB ; semantics = SPACE
<atom> ::= 1*(any <CHAR> except <specials>, SPACE and <CTL>s)
<CHAR> ::= <any ASCII character>
<CTL> ::= <any ASCII control character and DEL>
<specials> ::= "(" / ")" / "<" / ">" / "@" ; Must be in quoted-
/ "," / ";" / ":" / "
/ "." / "[" / "]" ; within a word.
Table of Contents Table of Contents
1 Status of this Memo ............................................. 1 1 Status of this Memo ............................................. 1
2 Abstract ........................................................ 1 2 Abstract ........................................................ 1
3 Applying PEM Security Services to MIME Body Parts ............... 2 3 Introduction .................................................... 2
3.1 PEM Processing Steps .......................................... 3 4 Name Forms and Identifiers ...................................... 3
3.1.1 Step 1: Local Form .......................................... 3 4.1 Name Forms .................................................... 4
3.1.2 Step 2: Canonical Form ...................................... 3 4.1.1 Email Addresses ............................................. 4
3.1.3 Step 3: Security Form ....................................... 5 4.1.2 Arbitrary Strings ........................................... 5
3.2 Use of multipart/signed Content Type .......................... 5 4.1.3 Distinguished Names ......................................... 5
3.3 Use of multipart/encrypted Content Type ....................... 6 4.2 Identifiers ................................................... 5
4 Removing PEM Security Services from PEM Body Parts .............. 7 4.2.1 Email Address ............................................... 6
5 Definition of New Name Forms .................................... 7 4.2.2 Arbitrary String ............................................ 6
6 Definition of New Content Types ................................. 9 4.2.3 Distinguished Name .......................................... 7
6.1 application/key-request Content Type Definition ............... 9 4.2.4 PGP Public Key .............................................. 7
6.2 application/key-data Content Type Definition .................. 10 4.2.5 Public Key .................................................. 7
7 Message Processing .............................................. 12 4.2.6 Issuer Name and Serial Number ............................... 8
7.1 Pre-Submission Algorithm ...................................... 12 5 Applying PEM Security Services to MIME Body Parts ............... 8
7.2 Post-Delivery Algorithm ....................................... 13 5.1 PEM Processing Steps .......................................... 8
8 Examples ........................................................ 13 5.2 Use of multipart/signed Content Type .......................... 10
9 Observations .................................................... 14 5.3 Use of multipart/encrypted Content Type ....................... 11
10 Summary of Changes to PEM Specification ........................ 14 6 Removing PEM Security Services from PEM Body Parts .............. 12
11 Collected Grammar .............................................. 16 7 Definition of New Content Types ................................. 13
12 Security Considerations ........................................ 18 7.1 application/key-request Content Type Definition ............... 13
13 Acknowledgements ............................................... 18 7.2 application/key-data Content Type Definition .................. 15
14 References ..................................................... 18 8 Examples ........................................................ 17
15 Authors' Addresses ............................................. 19 9 Observations .................................................... 17
16 Appendix: Imported Grammar ..................................... 20 10 Summary of Changes to PEM Specification ........................ 17
11 Collected Grammar .............................................. 19
12 Security Considerations ........................................ 22
13 Acknowledgements ............................................... 22
14 References ..................................................... 22
15 Authors' Addresses ............................................. 23
16 Appendix: Imported Grammar ..................................... 24
 End of changes. 70 change blocks. 
347 lines changed or deleted 533 lines changed or added

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