Internet Draft                              Steve Dusse,
draft-dusse-smime-cert-00.txt               RSA Data Security
March 25, 1997                              Paul Hoffman,
Expires September 25, 1997                  Internet Mail Consortium
                                            Blake Ramsdell,
                                            Deming Internet Security
                                            Laurence Lundblade,
                                            Lisa Repka,

                 S/MIME Certificate Handling

Status of this memo

This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.

Internet-Drafts are draft documents valid for a maximum of six months
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 the Internet-Drafts Shadow
Directories on (Africa), (Europe), (Pacific Rim), (US East Coast), or (US West Coast).

1. Overview

S/MIME (Secure/Multipurpose Internet Mail Extensions), described in
[SMIME-MSG], provides a standard way to send and receive secure MIME
messages. In order to validate the keys of a message sent to it, an
S/MIME agent needs to certify that the key is valid. This draft
describes the mechanisms S/MIME uses to create and validate keys using

This specification is compatible with PKCS #7 in that it uses the data
types defined by PKCS #7. It also inherits all the varieties of
architectures for certificate-based key management supported by PKCS
#7. Note that the method S/MIME messages make certificate requests is
defined in [SMIME-MSG].

In order to handle S/MIME certificates, an agent has to follow
specifications in this draft, as well as some of the specifications
listed in the following pre-standards works:
 - "PKCS #1: RSA Encryption Standard", [PKCS-1].
 - "PKCS #7: Cryptographic Message Syntax Standard", [PKCS-7]
 - "PKCS #9: Selected Attribute Types", [PKCS-9].
 - "PKCS #10: Certification Request Syntax Standard", [PKCS-10].

1.1 Definitions

For the purposes of this draft, the following definitions apply.

ASN.1: Abstract Syntax Notation One, as defined in CCITT X.208.

BER: Basic Encoding Rules for ASN.1, as defined in CCITT X.209.

Certificate: A type that binds an entity's distinguished name to a
public key with a digital signature. This type is defined in
CCITT X.509. This type also contains the distinguished name of
the certificate issuer (the signer), an issuer-specific serial number,
the issuer's signature algorithm identifier, and a validity period.

CertificateRevocationList (CRL): A type that contains information
about certificates whose validity an issuer has prematurely revoked.
The information consists of an issuer name, the time of issue, the
next scheduled time of issue, and a list of certificate serial numbers
and their associated revocation times. The CRL is signed by the
issuer. The type intended by this standard is the one defined in [KEYM].

DER: Distinguished Encoding Rules for ASN.1, as defined in CCITT
X.509, Section 8.7.

1.2 Compatibility with Pre-standards S/MIME

Appendix C contains importnat information about how standards-based
S/MIME agents should act in order to have the greatest interoperability
with pre-standards S/MIME.

2. PKCS #7 Options

The PKCS #7 message format allows for a wide variety of options in
content and algorithm support. This section puts forth a number of
support requirements and recommendations in order to achieve a base
level of interoperability among all S/MIME implementations.
Most of the PKCS #7 format for S/MIME messages is defined in

2.1 CertificateRevocationLists

Receiving agents MUST support for the Certificate Revocation List (CRL)
format defined in [KEYM].

It is anticipated that there will be a transition to the use of the
X.509 v2 CRL format. However, because insufficient profiling has taken
place to make this the default, agents SHOULD support for the X.509 v2
CRL format in incoming messages.

If sending agents include CRLs in outgoing messages, the CRL format
defined in [KEYM] SHOULD be used.

2.2 ExtendedCertificateOrCertificate

Receiving agents MUST support X.509 v1 and X.509 v2 certificates, and
SHOULD support X.509 v3 certificates. It is expected that, when the
specification for X.509 v3 certificates is finished, this S/MIME
specification will be altered to require X.509 v3 certificates.

Sending agents that include certificates on outgoing messages SHOULD use
the same type and version that was decided during the certification
request/fulfillment process.

2.2.1 Historical Note About PKCS #7 Certificates

The PKCS #7 message format supports a choice of certificate two
formats for public key content types: X.509 and PKCS #6 Extended
Certificates. The PKCS #6 format is not in widespread use. In
addition, proposed revisions of X.509 certificates address much of the
same functionality and flexibility as was intended in the PKCS #6.
Thus, sending and receiving agents MUST NOT use PKCS #6 extended

2.3 ExtendedCertificateAndCertificates

Receiving agents MUST be able to handle an arbitrary number of
certificates of arbitrary relationship to the message sender and to
each other in arbitrary order. In many cases, the certificates
included in a signed message may represent a chain of certification
from the sender to a particular root. There may be, however,
situations where the certificates in a signed message may be unrelated
and included for convenience.

Sending agents SHOULD include any certificates for the user's public
key(s) and associated issuer certificates. This increases the
likelihood that the intended recipient can establish trust in the
originator's public key(s). This is especially important when sending
a message to recipients that may not have access to the sender's
public key through any other means or when sending a signed message to
a new recipient. The inclusion of certificates in outgoing messages
can be omitted S/MIME objects are sent within a group of correspondents that
has established access to each other's certificates by some other
means such as a shared directory or manual certificate distribution.

3. Distinguished Names in Certificates

3.1 Using Distinguished Names for Internet Mail

The format of an X.509 certificate includes fields for the subject
name and issuer name. (The X.509 v1 certificate syntax is reproduced
in Appendix A to PKCS #6). The subject name identifies the owner of a
particular public key/private key pair while the issuer name is meant
to identify the entity that "certified" the subject (that is, who
signed the subject's certificate). The subject name and issuer name
are defined by X.509 as Distinguished Names.

Distinguished Names are defined by a CCITT standard X.501.  A
Distinguished Name is broken into one or more Relative Distinguished
Names. Each Relative Distinguished Name is comprised of one or more
Attribute-Value Assertions. Each Attribute-Value Assertion consists of
a Attribute Identifier and its corresponding value information, such
as CountryName=US. Distinguished Names were intended to identify
entities in the X.500 directory tree. Each Relative Distinguished Name
can be thought of as a node in the tree which is described by some
collection of Attribute-Value Assertions. The entire Distinguished
Name is some collection of nodes in the tree that traverse a path from
the root of the tree to some end node which represents a particular

The goal of the directory was to provide an infrastructure to uniquely
name every communications entity everywhere. However, adoption of a
global X.500 directory infrastructure has been slower than expected.
Consequently, there is no requirement for X.500 directory service
provision in the S/MIME environment, although such provision would
almost undoubtedly be of great value in facilitating key management
for S/MIME.

The use of Distinguished Names in accordance with the X.500 directory
is not very widespread. By contrast, Internet mail addresses, as
described in RFC 822, are used almost exclusively in the Internet
environment to identify originators and recipients of messages.
However, Internet mail addresses bear no resemblance to X.500
Distinguished Names (except, perhaps, that they are both hierarchical
in nature). Some method is needed to map Internet mail addresses to
entities that hold public keys. Some people have suggested that the
X.509 certificate format should be abandoned in favor of other binding
mechanisms. Instead, S/MIME keeps the X.509 certificate and
Distinguished Name mechanisms while tailoring the content of the
naming information to suit the Internet mail environment.

At a minimum, either the Distinguished Name used to identify an
Internet mail entity MUST include an Internet mail address, or some
other mechanism MUST be implemented in the user agent to provide for
mapping Distinguished Names to Internet mail address. If a mapping
mechanism is used, the mapping database MUST be protected from
tampering to defend against malicious insertion of non-trusted
certificates, CRLs, and chains.

The creation and use of a Distinguished Name which includes only an
Internet mail address as the subject name in an X.509 certificate
SHOULD be used for initial deployment of S/MIME. Such a construct,
however, does not conform to the CCITT standards for Distinguished
Names and should be used only as a transitional strategy. In many
environments, the eventual addition of classical Distinguished Name
attributes to the Internet mail address will be of value, such as for
inter-organization commerce. The decision of what kind of
Distinguished Name a user should construct will likely be influenced
by the environment in which S/MIME is used as well as by whatever
requirements are levied by the user's certifier or certification
service provider.

3.2 Required Name Attributes

Receiving agents MUST support parsing and display of zero, one, or more
instances of each of the following set of name attributes within the
Distinguished Names in certificates.

Sending agents SHOULD include the Internet mail address during
Distinguished Name creation. Guidelines for the inclusion, omission,
and ordering of the remaining name attributes during the creation of a
distinguished name will most likely be dictated by the policies
associated with the certification service which will certify the
corresponding name and public key.

Name Attribute           Description

CountryName              X.520
StateOrProvinceName      X.520
Locality                 X.520
CommonName               X.520
Title                    X.520
Organization             X.520
OrganizationalUnit       X.520
StreetAddress            X.520
Postal Code              X.520
Phone Number             X.520
e-mailAddress            PKCS #9

4. Certificate Processing

A receiving agent MUST provide some certificate retrieval mechanism in
order to gain access to certificates for recipients of digital
envelopes. There are many ways to implement certificate retrieval
mechanisms. X.500 directory service is an excellent example of a
certificate retrieval-only mechanism that is compatible with classic
X.500 Distinguished Names. Another method under consideration by the
IETF is to provide certificate retrieval services as part of the
existing Domain Name System (DNS). Until such mechanisms are widely
used, their utility may be limited by the small number of
correspondent's certificates that can be retrieved. At a minimum, for
initial S/MIME deployment, a user agent could automatically generate
a message to an intended recipient requesting that recipient's
certificate in a signed return message.

Receiving and sending agents SHOULD also provide a mechanism to allow a
user to "store and protect" certificates for correspondents in such a
way so as to guarantee their later retrieval. In many environments, it
may be desirable to link the certificate retrieval/storage mechanisms
together in some sort of certificate database. In its simplest form, a
certificate database would be local to a particular user and would
function in a similar way as a "address book" that stores a user's
frequent correspondents. In this way, the certificate retrieval
mechanism would be limited to the certificates that a user has stored
(presumably from incoming messages).  A comprehensive certificate
retrieval/storage solution may combine two or more mechanisms to allow
the greatest flexibility and utility to the user. For instance, a
secure Internet mail agent may resort to checking a centralized certificate
retrieval mechanism for a certificate if it can not be found in a
user's local certificate storage/retrieval database.

Receiving and sending agents SHOULD provide a mechanism for the import
and export of certificates, using a PKCS #7 certs-only message. This
allows for import and export of full certificate chains as opposed to
just a single certificate. This is described in [SMIME-MSG].

4.1 Certificate Revocation Lists

A receiving agent SHOULD have access to some certificate-revocation
list (CRL) retrieval mechanism in order to gain access to
certificate-revocation information when validating certificate chains.
A receiving or sending agent SHOULD also provide a mechanism to allow a
user to "store" incoming certificate-revocation information for
correspondents in such a way so as to guarantee its later retrieval,
however, it is always better to get the latest information from the CA
than to get information stored away from incoming messages.

Receiving and sending agents SHOULD retrieve and utilize CRL information
every time a certificate is verified as part of a certificate chain
validation even if the certificate was already verified in the past.
However, in many instances (such as off-line verification) access to
the latest CRL information may be difficult or impossible. The use of
CRL information, therefore, should be dictated by the value of the
information that is protected. The value of the CRL information in a
particular context is beyond the scope of this draft but may be
governed by the policies associated with particular certificate

4.2 Certificate Chain Validation

In creating a user agent for secure messaging, certificate, CRL, and
certificate chain validation SHOULD be highly automated while still
acting in the best interests of the user. Certificate, CRL, and chain
validation MUST be performed when validating a correspondent's public
key. This is necessary when a) verifying a signature from a
correspondent and, b) creating a digital envelope with the
correspondent as the intended recipient.

Certificates and CRLs are made available to the chain validation
procedure in two ways: a) incoming messages, and b) certificate
and CRL retrieval mechanisms. Certificates and CRLs in incoming
messages are not required to be in any particular order nor are they
required to be in any way related to the sender or recipient of the
message (although in most cases they will be related to the sender).
Incoming certificates and CRLs SHOULD be cached for use in chain
validation and optionally stored for later use. This temporary
certificate and CRL cache SHOULD be used to augment any other
certificate and CRL retrieval mechanisms for chain validation on
incoming signed messages.

4.3 Certificate and CRL Signing Algorithms

Certificates and Certificate-Revocation Lists (CRLs) are signed by the
certificate issuer. A receiving agent MUST be capable of verifying the
signatures on certificates and CRLs made with the
md2WithRSAEncryption, md5WithRSAEncryption and sha-1WithRSAEncryption
signature algorithms with key sizes from 512 bits to 2048 bits.

4.4 X.509 Version 3 Certificate Extensions

The X.509 v3 standard describes an extensible framework in which the
basic certificate information can be extended and how such extensions
can be used to control the process of issuing and validating
certificates. Because the v3 standard is relatively new, there are
ongoing efforts to identify and create extensions which have value in
particular certification environments. As such, there is still a fair
amount of profiling work to be done before there is widespread
agreement on which v3 extensions will be used. Further, there are
active efforts underway to issue X.509 v3 certificates for business
purposes. This draft identifies the smallest set of certificate
extensions which have the greatest value in the S/MIME environment.
The basicConstraints, keyUsage, and certificatePolicies extensions are
defined in the X.509 v3 draft; Amendment 1 to ISO/IEC 9594- 8:1995.

Sending and receiving agents MUST correctly handle and display the v3
Basic Constraints Certificate Extension, the Key Usage Certificate
Extension, and the Certificate Policy Certificate Extension when they
appear in end-user certificates. Some mechanism SHOULD exist to handle
and display the defined v3 certificate extensions when they appear in
intermediate or CA certificates.

In the S/MIME environment, CAs which issue v3 certificates SHOULD
include only the extensions listed in the subsections of this section.
For these extensions, the criticality flag SHOULD be set to False
unless the proper handling and display of the corresponding extension
is deemed critical to the correct interpretation of the associated
certificate. Also, in an S/MIME environment, when additional v3
extensions are included in a certificate, the corresponding
criticality flags SHOULD be set to False.

4.4.1 Basic Constraints Certificate Extension

The basic constraints extension serves to delimit the role and
position of an issuing authority or end-user certificate plays in
a chain of certificates.

For example, certificates issued to CAs and subordinate CAs
contain a basic constraint extension that identifies them as
issuing authority certificates. End-user subscriber certificates
contain an extension that constrains the certificate from being
an issuing authority certificate.

4.4.2 Key Usage Certificate Extension

The key usage extension serves to limit the technical purposes
for which a public key listed in a valid certificate may be used.
Issuing authority certificates may contain a key usage extension
that restricts the key to signing certificates, certificate
revocation lists and other data.

For example, a certification authority may create subordinate
issuer certs which contain a keyUsage extension which specifies
that the corresponding public key can be used to sign end user
certs and sign CRLs.

4.4.3 Certificate Policy Certificate Extension

The certificate policy extension limits a certificate to the
practices required by relying parties.

5. Generating Keys and Certification Requests

5.1 Binding Names and Keys

An S/MIME agent or some related administrative utility or function MUST
be capable of generating a certification request given a user's public
key and associated name information. In most cases, the user's public
key/private key pair will be generated simultaneously. However, there
are cases where the keying information may be generated by an external
process (such as when a key pair is generated on a cryptographic token
or by a "key recovery" service).

There SHOULD never exist multiple valid (that is, non-expired and
non-revoked) certificates for the same key pair bound to
different Distinguished Names. Otherwise, a security flaw exists
where an attacker can substitute one valid certificate for
another in such a way that can not be detected by a message
recipient. If a users wishes to change their name (or create an
alternate name), the user agent SHOULD generate a new key pair.
If the user wishes to reuse an existing key pair with a new or
alternate name, the user SHOULD first have any valid certificates
for the existing public key revoked.

In general, it is possible for a user to request certification
for the same name and key from multiple certification
authorities. This SHOULD not be done, however, because the policies
of different certification authorities may vary and this may
create confusion among a user's correspondents as to which policy
was used to certify the user.

In general, it is possible for a user to request certification
for the same name with multiple key pairs from the same or
different certification authorities. Although this may be
somewhat confusing, this is acceptable for end-user certificates
because the use of the Issuer Name/Serial Number pair in the PKCS
#7 automatically disambiguates each user certificate. The use of
the same name with different key pairs SHOULD not be done,
however, for issuer keys, since certificate chain processing
would be made more difficult by the task of having to "try" each
different issuer key when validating a certificate created by
that issuer.

5.2 Using PKCS #10 for Certification Requests

PKCS #10 is a flexible and extensible message format for representing
the results of cryptographic operations on some data. The choice of
naming information is largely dictated by the policies and procedures
associated with the intended certification service.

In addition to key and naming information, the PKCS #10 format
supports the inclusion of optional attributes, signed by the entity
requesting certification. This allows for information to be conveyed
in a certification request which may be useful to the request process,
but not necessarily part of the Distinguished Name being certified.

Certification authorities MUST support parsing and display of zero or
one instance of each of the following set of certification- request
attributes on incoming messages. Inclusion of the following attributes
during the creation and submission of a certification-request will
most likely be dictated by the policies associated with the
certification service which will certify the corresponding name and
public key.

Attribute                Description

postalAddress            X.520
challengePassword        PKCS #9
unstructuredAddress      PKCS #9
unstructuredName         PKCS #9

Receiving agents MUST support the identification of an RSA key with the
rsa OID defined in X.509 and the rsaEncryption OID. Certification
authorities MUST also support the verification of signatures on
certificate requests made with sha-1WithRSAEncryption,
md5WithRSAEncryption, and MD2WithRSAEncryption signature algorithms..

For the creation and submission of certification-requests, RSA keys
SHOULD be identified with the rsaEncryption OID and signed with the
sha-1WithRSAEncryption signature algorithm.

5.3 Fulfilling a Certification Request

Certification authorities SHOULD use the sha-1WithRSAEncryption
signature algorithms when signing certificates.

5.4 Using PKCS #7 for Fulfilled Certificate Response

[PKCS-7] supports a degenerate case of the SignedData content type
where there are no signers on the content (and hence, the content
value is "irrelevant"). This degenerate case is used to convey
certificate and CRL information. Certification authorities MUST use
this format for returning certificate information resulting from the
successful fulfillment of a certification request. At a minimum, the
fulfilled certificate response MUST include the actual subject
certificate (corresponding to the information in the certification
request). The response SHOULD include other certificates which
link the issuer to higher level certification authorities and
corresponding certificate-revocation lists. Unrelated certificates and
revocation information is also acceptable.

Receiving agents MUST parse this degenerate PKCS #7 message type and
handle the certificates and CRLs according to the requirements and
recommendations in Section 4.

6. Security Considerations

All of the security issues faced by any cryptographic application must
be faced by a S/MIME agent. Among these issues are protecting the user's
private key, preventing various attacks, and helping the user avoid
mistakes such as inadvertently encrypting a message for the wrong
recipient. The entire list of security considerations is beyond the
scope of this document, but some significant concerns are listed here.

An implementor may choose not to present data which has been digitally
signed if the signature verification fails. The reasoning is that if
the signature fails, the data very likely has been tampered with and
should be considered untrustworthy.  This is consistent with the fact
that the signed data within an application/pkcs7-mime entity cannot
be seen by viewing the "raw" MIME message, since it is base64 encoded
(unless is it sent clear signed). The message must be processed and
the signature verified before the data is presented. If the
implementor does choose to present the data even if the signature
verification fails, it is advisable to strongly warn the user.

A MIME agent which supports application/pkcs7-mime inherits the
certificate-based key management supported by PKCS #7. In particular,
a typical agent must be able to process certificates and CRLs which
may be included inside a SignedData or SignedAndEnvelopedData type.
The agent may also include auxiliary services to allow the user to
generate keys, submit and process certification requests and to
request updated CRLs.

Appendix A - Object Identifiers & Syntax

Sections A.1 through A.4 are adopted from [SMIME-MSG].

A.5 Name Attributes

emailAddress OBJECT IDENTIFIER ::=

     {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1}

     {joint-iso-ccitt(2) ds(5) attributeType(4) 6}

StateOrProvinceName OBJECT IDENTIFIER ::=
     {joint-iso-ccitt(2) ds(5) attributeType(4) 8}

     {joint-iso-ccitt(2) ds(5) attributeType(4) 7}

     {joint-iso-ccitt(2) ds(5) attributeType(4) 3}

     {joint-iso-ccitt(2) ds(5) attributeType(4) 12}

Organization OBJECT IDENTIFIER ::=
     {joint-iso-ccitt(2) ds(5) attributeType(4) 10}

OrganizationalUnit OBJECT IDENTIFIER ::=
     {joint-iso-ccitt(2) ds(5) attributeType(4) 11}

     {joint-iso-ccitt(2) ds(5) attributeType(4) 9}

     {joint-iso-ccitt(2) ds(5) attributeType(4) 17}

     {joint-iso-ccitt(2) ds(5) attributeType(4) 20}

A.6 Certification Request Attributes

postalAddress OBJECT IDENTIFIER ::=
     {joint-iso-ccitt(2) ds(5) attributeType(4) 16}

challengePassword OBJECT IDENTIFIER ::=
     {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9) 7}

unstructuredName OBJECT IDENTIFIER ::=
     {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9) 2}

unstructuredAddress OBJECT IDENTIFIER ::=
     {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9) 8}

A.7 X.509 V3 Certificate Extensions

basicConstraints OBJECT IDENTIFIER ::=

     {joint-iso-ccitt(2) ds(5) 29 19 }

The ASN.1 definition of basicConstraints certificate extension is:

basicConstraints basicConstraints EXTENSION ::= {
     SYNTAX  BasicConstraintsSyntax
     IDENTIFIED BY { id-ce 19 } }

BasicConstraintsSyntax ::= SEQUENCE {
     cA                 BOOLEAN DEFAULT FALSE,
     pathLenConstraint  INTEGER (0..MAX) OPTIONAL }

     {joint-iso-ccitt(2) ds(5) 29 15 }

The ASN.1 definition of keyUsage certificate extension is:

keyUsage EXTENSION ::= {
     SYNTAX  KeyUsage
     IDENTIFIED BY { id-ce 15 }}

KeyUsage ::= BIT STRING {
     digitalSignature      (0),
     nonRepudiation        (1),
     keyEncipherment       (2),
     dataEncipherment      (3),
     keyAgreement          (4),
     keyCertSign           (5),
     cRLSign               (6)}

certificatePolicies OBJECT IDENTIFIER ::=
     {joint-iso-ccitt(2) ds(5) 29 32}

The ASN.1 definition of certificatePolicies certificate extension

certificatePolicies EXTENSION ::= {
     SYNTAX  CertificatePoliciesSyntax
     IDENTIFIED BY { id-ce 32 }}

CertificatePoliciesSyntax ::=
     SEQUENCE SIZE (1..MAX) OF PolicyInformation

PolicyInformation ::= SEQUENCE {
     policyIdentifier   CertPolicyId,
          SEQUENCE SIZE (1..MAX) OF PolicyQualifierInfo OPTIONAL }


PolicyQualifierInfo ::= SEQUENCE {
     policyQualifierId CERT-POLICY-QUALIFIER.&id
     qualifier CERT-POLICY-QUALIFIER.&Qualifier

({SupportedPolicyQualifiers}{@policyQualifierId}) OPTIONAL }

SupportedPolicyQualifiers CERT-POLICY-QUALIFIER ::= {...}

     &Qualifier      OPTIONAL }
          POLICY-QUALIFIER-ID     &id [QUALIFIER-TYPE &Qualifier] }

B. References

[KEYM] "PEM key management", RFC 1422

[PEM] "Privacy-Enhanced Mail (PEM) basics", RFC 1421

[PKCS-1], "PKCS #1: RSA Encryption Standard", submission of draft

[PKCS-7], "PKCS #7: Cryptographic Message Syntax Standard", submission
of draft pending

[PKCS-9], "PKCS #9: Selected Attribute Types", submission of draft

[PKCS-10], "PKCS #10: Certification Request Syntax Standard",
submission of draft pending

[SMIME-MSG] "S/MIME Message Specification", Internet Draft

C. Compatibility with Pre-standards S/MIME

S/MIME was originally developed by RSA Data Security, Inc. Many
developers implemented S/MIME agents before the standard was turned
over to the IETF. All S/MIME receiving agents SHOULD make every attempt to
interoperate with pre-standards S/MIME sending agents.

C.1 Pre-standards MIME Types

Pre-standard S/MIME agents used the following MIME types:


In each case, the "x-" subtypes correspond to the subtypes described
in this document without the "x-".

D. Revision History

This draft is a combination of an earlier draft,
draft-dusse-mime-msg-spec-00, which specified the format for S/MIME
messages, and the "S/MIME Implementation Guide, Interoperability
Profiles, Version 2", a document from RSA Data Security. This draft
includes changes to the wording, but not the intent, of both
documents. Part of the "Implementation Guide" document was split
out into a draft that describes S/MIME certification issues.

E. Open Issues

Make the draft more definitive by:
 - removing X.509 v2
 - making X.509 v3 required instead of recommended
 - removing section 2.2 recommendation that sending agents use same
   type and version.

Whether or not the PKCS-nn documents will be IETF RFCs or simply be
referenced as external documents.

References to the encryption and hash algorithms.

Use of the S/MIME trademark.

F.  Trademarks

RSA Data Security, Inc., owns the US trademark for the name "S/MIME"
and for a logo associated with that name. RSA Data Security, Inc., is
currently in discussions with the IETF about the use of the name
"S/MIME" for interoperable message security. The name "S/MIME" may or
may not be used in future versions of this draft.

G. Acknowledgements

Significant contributions to the content of this draft were made by
many people, including:
Jeff Thompson
Jeff Weinstein

H. Authors' addresses

Steve Dusse
RSA Data Security, Inc.
100 Marine Parkway, #500
Redwood City, CA  94065  USA
(415) 595-8782

Paul Hoffman
Internet Mail Consortium
127 Segre Place
Santa Cruz, CA  95060
(408) 426-9827

Blake Ramsdell
Deming Internet Security
13122 NE 20th St., Suite C
Bellevue, WA 98005
(206) 882-8861

Laurence Lundblade
QUALCOMM Incorporated
Eudora Division
6455 Lusk Boulevard
San Diego, California 92121-2779
(800) 238-3672

Lisa Repka
Netscape Communications Corporation
501 East Middlefield Road
Mountain View, CA  94043
(415) 254-1900