doc: Add RFC documents

1 files changed, 2019 insertions, 0 deletions

diff --git a/doc/rfc/rfc3851.txt b/doc/rfc/rfc3851.txt
new file mode 100644
index 0000000..1c9843d
--- /dev/null
+++ b/doc/rfc/rfc3851.txt
@@ -0,0 +1,2019 @@
+
+
+
+
+
+
+Network Working Group                                B. Ramsdell, Editor
+Request for Comments: 3851                                Sendmail, Inc.
+Obsoletes: 2633                                                July 2004
+Category: Standards Track
+
+
+   Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.1
+                         Message Specification
+
+Status of this Memo
+
+   This document specifies an Internet standards track protocol for the
+   Internet community, and requests discussion and suggestions for
+   improvements.  Please refer to the current edition of the "Internet
+   Official Protocol Standards" (STD 1) for the standardization state
+   and status of this protocol.  Distribution of this memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (2004).
+
+Abstract
+
+   This document defines Secure/Multipurpose Internet Mail Extensions
+   (S/MIME) version 3.1.  S/MIME provides a consistent way to send and
+   receive secure MIME data.  Digital signatures provide authentication,
+   message integrity, and non-repudiation with proof of origin.
+   Encryption provides data confidentiality.  Compression can be used to
+   reduce data size.  This document obsoletes RFC 2633.
+
+Table of Contents
+
+   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
+       1.1.  Specification Overview . . . . . . . . . . . . . . . . .  3
+       1.2.  Terminology. . . . . . . . . . . . . . . . . . . . . . .  3
+       1.3.  Definitions. . . . . . . . . . . . . . . . . . . . . . .  4
+       1.4.  Compatibility with Prior Practice of S/MIME. . . . . . .  5
+       1.5.  Changes Since S/MIME v3. . . . . . . . . . . . . . . . .  5
+   2.  CMS Options. . . . . . . . . . . . . . . . . . . . . . . . . .  5
+       2.1.  DigestAlgorithmIdentifier. . . . . . . . . . . . . . . .  5
+       2.2.  SignatureAlgorithmIdentifier . . . . . . . . . . . . . .  6
+       2.3.  KeyEncryptionAlgorithmIdentifier . . . . . . . . . . . .  6
+       2.4.  General Syntax . . . . . . . . . . . . . . . . . . . . .  6
+       2.5.  Attributes and the SignerInfo Type . . . . . . . . . . .  7
+       2.6.  SignerIdentifier SignerInfo Type . . . . . . . . . . . . 11
+       2.7.  ContentEncryptionAlgorithmIdentifier . . . . . . . . . . 12
+   3.  Creating S/MIME Messages . . . . . . . . . . . . . . . . . . . 14
+
+
+
+
+Ramsdell                    Standards Track                     [Page 1]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+       3.1.  Preparing the MIME Entity for Signing, Enveloping
+             or Compressing . . . . . . . . . . . . . . . . . . . . . 14
+       3.2.  The application/pkcs7-mime Type. . . . . . . . . . . . . 19
+       3.3.  Creating an Enveloped-only Message . . . . . . . . . . . 21
+       3.4.  Creating a Signed-only Message . . . . . . . . . . . . . 22
+       3.5.  Creating an Compressed-only Message. . . . . . . . . . . 26
+       3.6.  Multiple Operations. . . . . . . . . . . . . . . . . . . 27
+       3.7.  Creating a Certificate Management Messagetoc . . . . . . 27
+       3.8.  Registration Requests. . . . . . . . . . . . . . . . . . 28
+       3.9.  Identifying an S/MIME Message. . . . . . . . . . . . . . 28
+   4.  Certificate Processing . . . . . . . . . . . . . . . . . . . . 29
+       4.1.  Key Pair Generation. . . . . . . . . . . . . . . . . . . 29
+   5.  Security Considerations. . . . . . . . . . . . . . . . . . . . 29
+   A.  ASN.1 Module . . . . . . . . . . . . . . . . . . . . . . . . . 31
+   B.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 32
+       B.1.  Normative References . . . . . . . . . . . . . . . . . . 32
+       B.2.  Informative References . . . . . . . . . . . . . . . . . 34
+   C.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
+   D.  Editor's Address . . . . . . . . . . . . . . . . . . . . . . . 35
+       Full Copyright Statement . . . . . . . . . . . . . . . . . . . 36
+
+1.  Introduction
+
+   S/MIME (Secure/Multipurpose Internet Mail Extensions) provides a
+   consistent way to send and receive secure MIME data.  Based on the
+   popular Internet MIME standard, S/MIME provides the following
+   cryptographic security services for electronic messaging
+   applications:  authentication, message integrity and non-repudiation
+   of origin (using digital signatures), and data confidentiality (using
+   encryption).
+
+   S/MIME can be used by traditional mail user agents (MUAs) to add
+   cryptographic security services to mail that is sent, and to
+   interpret cryptographic security services in mail that is received.
+   However, S/MIME is not restricted to mail; it can be used with any
+   transport mechanism that transports MIME data, such as HTTP.  As
+   such, S/MIME takes advantage of the object-based features of MIME and
+   allows secure messages to be exchanged in mixed-transport systems.
+
+   Further, S/MIME can be used in automated message transfer agents that
+   use cryptographic security services that do not require any human
+   intervention, such as the signing of software-generated documents and
+   the encryption of FAX messages sent over the Internet.
+
+
+
+
+
+
+
+
+Ramsdell                    Standards Track                     [Page 2]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+1.1.  Specification Overview
+
+   This document describes a protocol for adding cryptographic signature
+   and encryption services to MIME data.  The MIME standard [MIME-SPEC]
+   provides a general structure for the content type of Internet
+   messages and allows extensions for new content type applications.
+
+   This specification defines how to create a MIME body part that has
+   been cryptographically enhanced according to CMS [CMS], which is
+   derived from PKCS #7 [PKCS-7].  This specification also defines the
+   application/pkcs7-mime MIME type that can be used to transport those
+   body parts.
+
+   This document also discusses how to use the multipart/signed MIME
+   type defined in [MIME-SECURE] to transport S/MIME signed messages.
+   multipart/signed is used in conjunction with the application/pkcs7-
+   signature MIME type, which is used to transport a detached S/MIME
+   signature.
+
+   In order to create S/MIME messages, an S/MIME agent MUST follow the
+   specifications in this document, as well as the specifications listed
+   in the Cryptographic Message Syntax document [CMS] [CMSALG].
+
+   Throughout this specification, there are requirements and
+   recommendations made for how receiving agents handle incoming
+   messages.  There are separate requirements and recommendations for
+   how sending agents create outgoing messages.  In general, the best
+   strategy is to "be liberal in what you receive and conservative in
+   what you send".  Most of the requirements are placed on the handling
+   of incoming messages while the recommendations are mostly on the
+   creation of outgoing messages.
+
+   The separation for requirements on receiving agents and sending
+   agents also derives from the likelihood that there will be S/MIME
+   systems that involve software other than traditional Internet mail
+   clients.  S/MIME can be used with any system that transports MIME
+   data.  An automated process that sends an encrypted message might not
+   be able to receive an encrypted message at all, for example.  Thus,
+   the requirements and recommendations for the two types of agents are
+   listed separately when appropriate.
+
+1.2.  Terminology
+
+   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+   document are to be interpreted as described in [MUSTSHOULD].
+
+
+
+
+
+Ramsdell                    Standards Track                     [Page 3]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+1.3.  Definitions
+
+   For the purposes of this specification, the following definitions
+   apply.
+
+   ASN.1: Abstract Syntax Notation One, as defined in CCITT X.208
+   [X.208-88].
+
+   BER: Basic Encoding Rules for ASN.1, as defined in CCITT X.209
+   [X.209-88].
+
+   Certificate: A type that binds an entity's name to a public key with
+   a digital signature.
+
+   DER: Distinguished Encoding Rules for ASN.1, as defined in CCITT
+   X.509 [X.509-88].
+
+   7-bit data: Text data with lines less than 998 characters long, where
+   none of the characters have the 8th bit set, and there are no NULL
+   characters.  <CR> and <LF> occur only as part of a <CR><LF> end of
+   line delimiter.
+
+   8-bit data: Text data with lines less than 998 characters, and where
+   none of the characters are NULL characters. <CR> and <LF> occur only
+   as part of a <CR><LF> end of line delimiter.
+
+   Binary data: Arbitrary data.
+
+   Transfer Encoding: A reversible transformation made on data so 8-bit
+   or binary data can be sent via a channel that only transmits 7-bit
+   data.
+
+   Receiving agent: Software that interprets and processes S/MIME CMS
+   objects, MIME body parts that contain CMS content types, or both.
+
+   Sending agent: Software that creates S/MIME CMS content types, MIME
+   body parts that contain CMS content types, or both.
+
+   S/MIME agent: User software that is a receiving agent, a sending
+   agent, or both.
+
+
+
+
+
+
+
+
+
+
+
+Ramsdell                    Standards Track                     [Page 4]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+1.4.  Compatibility with Prior Practice of S/MIME
+
+   S/MIME version 3.1 agents SHOULD attempt to have the greatest
+   interoperability possible with agents for prior versions of S/MIME.
+   S/MIME version 2 is described in RFC 2311 through RFC 2315, inclusive
+   and S/MIME version 3 is described in RFC 2630 through RFC 2634
+   inclusive.  RFC 2311 also has historical information about the
+   development of S/MIME.
+
+1.5.  Changes Since S/MIME v3
+
+   The RSA public key algorithm was changed to a MUST implement key
+   wrapping algorithm, and the Diffie-Hellman algorithm changed to a
+   SHOULD implement.
+
+   The AES symmetric encryption algorithm has been included as a SHOULD
+   implement.
+
+   The RSA public key algorithm was changed to a MUST implement
+   signature algorithm.
+
+   Ambiguous language about the use of "empty" SignedData messages to
+   transmit certificates was clarified to reflect that transmission of
+   certificate revocation lists is also allowed.
+
+   The use of binary encoding for some MIME entities is now explicitly
+   discussed.
+
+   Header protection through the use of the message/rfc822 MIME type has
+   been added.
+
+   Use of the CompressedData CMS type is allowed, along with required
+   MIME type and file extension additions.
+
+2.  CMS Options
+
+   CMS 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. [CMSALG] provides
+   additional details regarding the use of the cryptographic algorithms.
+
+2.1.  DigestAlgorithmIdentifier
+
+   Sending and receiving agents MUST support SHA-1 [CMSALG].  Receiving
+   agents SHOULD support MD5 [CMSALG] for the purpose of providing
+   backward compatibility with MD5-digested S/MIME v2 SignedData
+   objects.
+
+
+
+Ramsdell                    Standards Track                     [Page 5]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+2.2.  SignatureAlgorithmIdentifier
+
+   Receiving agents MUST support id-dsa-with-sha1 defined in [CMSALG].
+   The algorithm parameters MUST be absent (not encoded as NULL).
+   Receiving agents MUST support rsaEncryption, defined in [CMSALG].
+
+   Sending agents MUST support either id-dsa-with-sha1 or rsaEncryption.
+
+   If using rsaEncryption, sending and receiving agents MUST support the
+   digest algorithms in section 2.1 as specified.
+
+   Note that S/MIME v3 clients might only implement signing or signature
+   verification using id-dsa-with-sha1, and might also use id-dsa as an
+   AlgorithmIdentifier in this field.  Receiving clients SHOULD
+   recognize id-dsa as equivalent to id-dsa-with-sha1, and sending
+   clients MUST use id-dsa-with-sha1 if using that algorithm.  Also note
+   that S/MIME v2 clients are only required to verify digital signatures
+   using the rsaEncryption algorithm with SHA-1 or MD5, and might not
+   implement id-dsa-with-sha1 or id-dsa at all.
+
+2.3.  KeyEncryptionAlgorithmIdentifier
+
+   Sending and receiving agents MUST support rsaEncryption, defined in
+   [CMSALG].
+
+   Sending and receiving agents SHOULD support Diffie-Hellman defined in
+   [CMSALG], using the ephemeral-static mode.
+
+   Note that S/MIME v3 clients might only implement key encryption and
+   decryption using the Diffie-Hellman algorithm.  Also note that S/MIME
+   v2 clients are only capable of decrypting content-encryption keys
+   using the rsaEncryption algorithm.
+
+2.4.  General Syntax
+
+   There are several CMS content types.  Of these, only the Data,
+   SignedData, EnvelopedData, and CompressedData content types are
+   currently used for S/MIME.
+
+2.4.1.  Data Content Type
+
+   Sending agents MUST use the id-data content type identifier to
+   identify the "inner" MIME message content.  For example, when
+   applying a digital signature to MIME data, the CMS SignedData
+   encapContentInfo eContentType MUST include the id-data object
+   identifier and the MIME content MUST be stored in the SignedData
+   encapContentInfo eContent OCTET STRING (unless the sending agent is
+   using multipart/signed, in which case the eContent is absent, per
+
+
+
+Ramsdell                    Standards Track                     [Page 6]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+   section 3.4.3 of this document).  As another example, when applying
+   encryption to MIME data, the CMS EnvelopedData encryptedContentInfo
+   contentType MUST include the id-data object identifier and the
+   encrypted MIME content MUST be stored in the EnvelopedData
+   encryptedContentInfo encryptedContent OCTET STRING.
+
+2.4.2.  SignedData Content Type
+
+   Sending agents MUST use the SignedData content type to apply a
+   digital signature to a message or, in a degenerate case where there
+   is no signature information, to convey certificates.  Applying a
+   signature to a message provides authentication, message integrity,
+   and non-repudiation of origin.
+
+2.4.3.  EnvelopedData Content Type
+
+   This content type is used to apply data confidentiality to a message.
+   A sender needs to have access to a public key for each intended
+   message recipient to use this service.
+
+2.4.4.  CompressedData Content Type
+
+   This content type is used to apply data compression to a message.
+   This content type does not provide authentication, message integrity,
+   non-repudiation, or data confidentiality, and is only used to reduce
+   message size.
+
+   See section 3.6 for further guidance on the use of this type in
+   conjunction with other CMS types.
+
+2.5.  Attributes and the SignerInfo Type
+
+   The SignerInfo type allows the inclusion of unsigned and signed
+   attributes to be included along with a signature.
+
+   Receiving agents MUST be able to handle zero or one instance of each
+   of the signed attributes listed here.  Sending agents SHOULD generate
+   one instance of each of the following signed attributes in each
+   S/MIME message:
+
+   -  signingTime (section 2.5.1 in this document)
+   -  sMIMECapabilities (section 2.5.2 in this document)
+   -  sMIMEEncryptionKeyPreference (section 2.5.3 in this document)
+   -  id-messageDigest (section 11.2 in [CMS])
+   -  id-contentType (section 11.1 in [CMS])
+
+
+
+
+
+
+Ramsdell                    Standards Track                     [Page 7]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+   Further, receiving agents SHOULD be able to handle zero or one
+   instance in the signingCertificate signed attribute, as defined in
+   section 5 of [ESS].
+
+   Sending agents SHOULD generate one instance of the signingCertificate
+   signed attribute in each SignerInfo structure.
+
+   Additional attributes and values for these attributes might be
+   defined in the future.  Receiving agents SHOULD handle attributes or
+   values that it does not recognize in a graceful manner.
+
+   Interactive sending agents that include signed attributes that are
+   not listed here SHOULD display those attributes to the user, so that
+   the user is aware of all of the data being signed.
+
+2.5.1.  Signing-Time Attribute
+
+   The signing-time attribute is used to convey the time that a message
+   was signed.  The time of signing will most likely be created by a
+   message originator and therefore is only as trustworthy as the
+   originator.
+
+   Sending agents MUST encode signing time through the year 2049 as
+   UTCTime; signing times in 2050 or later MUST be encoded as
+   GeneralizedTime.  When the UTCTime CHOICE is used, S/MIME agents MUST
+   interpret the year field (YY) as follows:
+
+   if YY is greater than or equal to 50, the year is interpreted as
+   19YY; if YY is less than 50, the year is interpreted as 20YY.
+
+2.5.2.  SMIMECapabilities Attribute
+
+   The SMIMECapabilities attribute includes signature algorithms (such
+   as "sha1WithRSAEncryption"), symmetric algorithms (such as "DES-
+   EDE3-CBC"), and key encipherment algorithms (such as
+   "rsaEncryption").  There are also several identifiers which indicate
+   support for other optional features such as binary encoding and
+   compression.  The SMIMECapabilities were designed to be flexible and
+   extensible so that, in the future, a means of identifying other
+   capabilities and preferences such as certificates can be added in a
+   way that will not cause current clients to break.
+
+   If present, the SMIMECapabilities attribute MUST be a
+   SignedAttribute; it MUST NOT be an UnsignedAttribute.  CMS defines
+   SignedAttributes as a SET OF Attribute.  The SignedAttributes in a
+   signerInfo MUST NOT include multiple instances of the
+   SMIMECapabilities attribute.  CMS defines the ASN.1 syntax for
+   Attribute to include attrValues SET OF AttributeValue.  A
+
+
+
+Ramsdell                    Standards Track                     [Page 8]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+   SMIMECapabilities attribute MUST only include a single instance of
+   AttributeValue.  There MUST NOT be zero or multiple instances of
+   AttributeValue present in the attrValues SET OF AttributeValue.
+
+   The semantics of the SMIMECapabilities attribute specify a partial
+   list as to what the client announcing the SMIMECapabilities can
+   support.  A client does not have to list every capability it
+   supports, and need not list all its capabilities so that the
+   capabilities list doesn't get too long.  In an SMIMECapabilities
+   attribute, the object identifiers (OIDs) are listed in order of their
+   preference, but SHOULD be separated logically along the lines of
+   their categories (signature algorithms, symmetric algorithms, key
+   encipherment algorithms, etc.)
+
+   The structure of the SMIMECapabilities attribute is to facilitate
+   simple table lookups and binary comparisons in order to determine
+   matches.  For instance, the DER-encoding for the SMIMECapability for
+   DES EDE3 CBC MUST be identically encoded regardless of the
+   implementation.  Because of the requirement for identical encoding,
+   individuals documenting algorithms to be used in the
+   SMIMECapabilities attribute SHOULD explicitly document the correct
+   byte sequence for the common cases.
+
+   For any capability, the associated parameters for the OID MUST
+   specify all of the parameters necessary to differentiate between two
+   instances of the same algorithm.  For instance, the number of rounds
+   and the block size for RC5 needs to be specified in addition to the
+   key length.
+
+   The OIDs that correspond to algorithms SHOULD use the same OID as the
+   actual algorithm, except in the case where the algorithm usage is
+   ambiguous from the OID.  For instance, in an earlier specification,
+   rsaEncryption was ambiguous because it could refer to either a
+   signature algorithm or a key encipherment algorithm.  In the event
+   that an OID is ambiguous, it needs to be arbitrated by the maintainer
+   of the registered SMIMECapabilities list as to which type of
+   algorithm will use the OID, and a new OID MUST be allocated under the
+   smimeCapabilities OID to satisfy the other use of the OID.
+
+   The registered SMIMECapabilities list specifies the parameters for
+   OIDs that need them, most notably key lengths in the case of
+   variable-length symmetric ciphers.  In the event that there are no
+   differentiating parameters for a particular OID, the parameters MUST
+   be omitted, and MUST NOT be encoded as NULL.
+
+
+
+
+
+
+
+Ramsdell                    Standards Track                     [Page 9]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+   Additional values for the SMIMECapabilities attribute might be
+   defined in the future.  Receiving agents MUST handle a
+   SMIMECapabilities object that has values that it does not recognize
+   in a graceful manner.
+
+   Section 2.7.1 explains a strategy for caching capabilities.
+
+2.5.2.1.  SMIMECapability For the RC2 Algorithm
+
+   For the RC2 algorithm preference SMIMECapability, the capabilityID
+   MUST be set to the value rc2-cbc as defined in [CMSALG].  The
+   parameters field MUST contain SMIMECapabilitiesParametersForRC2CBC
+   (see appendix A).
+
+   Please note that the SMIMECapabilitiesParametersForRC2CBC is a single
+   INTEGER which contains the effective key length (NOT the
+   corresponding RC2 parameter version value).  So, for example, for RC2
+   with a 128-bit effective key length, the parameter would be encoded
+   as the INTEGER value 128, NOT the corresponding parameter version of
+   58.
+
+2.5.3.  Encryption Key Preference Attribute
+
+   The encryption key preference attribute allows the signer to
+   unambiguously describe which of the signer's certificates has the
+   signer's preferred encryption key.  This attribute is designed to
+   enhance behavior for interoperating with those clients that use
+   separate keys for encryption and signing.  This attribute is used to
+   convey to anyone viewing the attribute which of the listed
+   certificates is appropriate for encrypting a session key for future
+   encrypted messages.
+
+   If present, the SMIMEEncryptionKeyPreference attribute MUST be a
+   SignedAttribute; it MUST NOT be an UnsignedAttribute.  CMS defines
+   SignedAttributes as a SET OF Attribute.  The SignedAttributes in a
+   signerInfo MUST NOT include multiple instances of the
+   SMIMEEncryptionKeyPreference attribute.  CMS defines the ASN.1 syntax
+   for Attribute to include attrValues SET OF AttributeValue.  A
+   SMIMEEncryptionKeyPreference attribute MUST only include a single
+   instance of AttributeValue.  There MUST NOT be zero or multiple
+   instances of AttributeValue present in the attrValues SET OF
+   AttributeValue.
+
+   The sending agent SHOULD include the referenced certificate in the
+   set of certificates included in the signed message if this attribute
+   is used.  The certificate MAY be omitted if it has been previously
+   made available to the receiving agent.  Sending agents SHOULD use
+   this attribute if the commonly used or preferred encryption
+
+
+
+Ramsdell                    Standards Track                    [Page 10]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+   certificate is not the same as the certificate used to sign the
+   message.
+
+   Receiving agents SHOULD store the preference data if the signature on
+   the message is valid and the signing time is greater than the
+   currently stored value. (As with the SMIMECapabilities, the clock
+   skew SHOULD be checked and the data not used if the skew is too
+   great.)  Receiving agents SHOULD respect the sender's encryption key
+   preference attribute if possible.  This, however, represents only a
+   preference and the receiving agent can use any certificate in
+   replying to the sender that is valid.
+
+   Section 2.7.1 explains a strategy for caching preference data.
+
+2.5.3.1.  Selection of Recipient Key Management Certificate
+
+   In order to determine the key management certificate to be used when
+   sending a future CMS EnvelopedData message for a particular
+   recipient, the following steps SHOULD be followed:
+
+   -  If an SMIMEEncryptionKeyPreference attribute is found in a
+      SignedData object received from the desired recipient, this
+      identifies the X.509 certificate that SHOULD be used as the X.509
+      key management certificate for the recipient.
+
+   -  If an SMIMEEncryptionKeyPreference attribute is not found in a
+      SignedData object received from the desired recipient, the set of
+      X.509 certificates SHOULD be searched for a X.509 certificate with
+      the same subject name as the signing of a X.509 certificate which
+      can be used for key management.
+
+   -  Or use some other method of determining the user's key management
+      key.  If a X.509 key management certificate is not found, then
+      encryption cannot be done with the signer of the message.  If
+      multiple X.509 key management certificates are found, the S/MIME
+      agent can make an arbitrary choice between them.
+
+2.6.  SignerIdentifier SignerInfo Type
+
+   S/MIME v3.1 implementations MUST support both issuerAndSerialNumber
+   as well as subjectKeyIdentifier.  Messages that use the
+   subjectKeyIdentifier choice cannot be read by S/MIME v2 clients.
+
+   It is important to understand that some certificates use a value for
+   subjectKeyIdentifier that is not suitable for uniquely identifying a
+   certificate.  Implementations MUST be prepared for multiple
+   certificates for potentially different entities to have the same
+   value for subjectKeyIdentifier, and MUST be prepared to try each
+
+
+
+Ramsdell                    Standards Track                    [Page 11]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+   matching certificate during signature verification before indicating
+   an error condition.
+
+2.7.  ContentEncryptionAlgorithmIdentifier
+
+   Sending and receiving agents MUST support encryption and decryption
+   with DES EDE3 CBC, hereinafter called "tripleDES" [CMSALG].
+   Receiving agents SHOULD support encryption and decryption using the
+   RC2 [CMSALG] or a compatible algorithm at a key size of 40 bits,
+   hereinafter called "RC2/40".  Sending and receiving agents SHOULD
+   support encryption and decryption with AES [CMSAES] at a key size of
+   128, 192, and 256 bits.
+
+2.7.1.  Deciding Which Encryption Method To Use
+
+   When a sending agent creates an encrypted message, it has to decide
+   which type of encryption to use.  The decision process involves using
+   information garnered from the capabilities lists included in messages
+   received from the recipient, as well as out-of-band information such
+   as private agreements, user preferences, legal restrictions, and so
+   on.
+
+   Section 2.5.2 defines a method by which a sending agent can
+   optionally announce, among other things, its decrypting capabilities
+   in its order of preference.  The following method for processing and
+   remembering the encryption capabilities attribute in incoming signed
+   messages SHOULD be used.
+
+   -  If the receiving agent has not yet created a list of capabilities
+      for the sender's public key, then, after verifying the signature
+      on the incoming message and checking the timestamp, the receiving
+      agent SHOULD create a new list containing at least the signing
+      time and the symmetric capabilities.
+
+   -  If such a list already exists, the receiving agent SHOULD verify
+      that the signing time in the incoming message is greater than the
+      signing time stored in the list and that the signature is valid.
+      If so, the receiving agent SHOULD update both the signing time and
+      capabilities in the list.  Values of the signing time that lie far
+      in the future (that is, a greater discrepancy than any reasonable
+      clock skew), or a capabilities list in messages whose signature
+      could not be verified, MUST NOT be accepted.
+
+   The list of capabilities SHOULD be stored for future use in creating
+   messages.
+
+   Before sending a message, the sending agent MUST decide whether it is
+   willing to use weak encryption for the particular data in the
+
+
+
+Ramsdell                    Standards Track                    [Page 12]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+   message.  If the sending agent decides that weak encryption is
+   unacceptable for this data, then the sending agent MUST NOT use a
+   weak algorithm such as RC2/40.  The decision to use or not use weak
+   encryption overrides any other decision in this section about which
+   encryption algorithm to use.
+
+   Sections 2.7.2.1 through 2.7.2.4 describe the decisions a sending
+   agent SHOULD use in deciding which type of encryption will be applied
+   to a message.  These rules are ordered, so the sending agent SHOULD
+   make its decision in the order given.
+
+2.7.1.1.  Rule 1: Known Capabilities
+
+   If the sending agent has received a set of capabilities from the
+   recipient for the message the agent is about to encrypt, then the
+   sending agent SHOULD use that information by selecting the first
+   capability in the list (that is, the capability most preferred by the
+   intended recipient) that the sending agent knows how to encrypt.  The
+   sending agent SHOULD use one of the capabilities in the list if the
+   agent reasonably expects the recipient to be able to decrypt the
+   message.
+
+2.7.1.2.  Rule 2: Unknown Capabilities, Unknown Version of S/MIME
+
+   If the following two conditions are met:
+   -  the sending agent has no knowledge of the encryption capabilities
+      of the recipient,
+   -  and the sending agent has no knowledge of the version of S/MIME of
+      the recipient,
+   then the sending agent SHOULD use tripleDES because it is a stronger
+   algorithm and is required by S/MIME v3.  If the sending agent chooses
+   not to use tripleDES in this step, it SHOULD use RC2/40.
+
+2.7.2.  Choosing Weak Encryption
+
+   Like all algorithms that use 40 bit keys, RC2/40 is considered by
+   many to be weak encryption.  A sending agent that is controlled by a
+   human SHOULD allow a human sender to determine the risks of sending
+   data using RC2/40 or a similarly weak encryption algorithm before
+   sending the data, and possibly allow the human to use a stronger
+   encryption method such as tripleDES.
+
+2.7.3.  Multiple Recipients
+
+   If a sending agent is composing an encrypted message to a group of
+   recipients where the encryption capabilities of some of the
+   recipients do not overlap, the sending agent is forced to send more
+   than one message.  Please note that if the sending agent chooses to
+
+
+
+Ramsdell                    Standards Track                    [Page 13]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+   send a message encrypted with a strong algorithm, and then send the
+   same message encrypted with a weak algorithm, someone watching the
+   communications channel could learn the contents of the strongly-
+   encrypted message simply by decrypting the weakly-encrypted message.
+
+3.  Creating S/MIME Messages
+
+   This section describes the S/MIME message formats and how they are
+   created.  S/MIME messages are a combination of MIME bodies and CMS
+   content types.  Several MIME types as well as several CMS content
+   types are used.  The data to be secured is always a canonical MIME
+   entity.  The MIME entity and other data, such as certificates and
+   algorithm identifiers, are given to CMS processing facilities which
+   produce a CMS object.  Finally, the CMS object is wrapped in MIME.
+   The Enhanced Security Services for S/MIME [ESS] document provides
+   descriptions of how nested, secured S/MIME messages are formatted.
+   ESS provides a description of how a triple-wrapped S/MIME message is
+   formatted using multipart/signed and application/pkcs7-mime for the
+   signatures.
+
+   S/MIME provides one format for enveloped-only data, several formats
+   for signed-only data, and several formats for signed and enveloped
+   data.  Several formats are required to accommodate several
+   environments, in particular for signed messages.  The criteria for
+   choosing among these formats are also described.
+
+   The reader of this section is expected to understand MIME as
+   described in [MIME-SPEC] and [MIME-SECURE].
+
+3.1.  Preparing the MIME Entity for Signing, Enveloping or Compressing
+
+   S/MIME is used to secure MIME entities.  A MIME entity can be a sub-
+   part, sub-parts of a message, or the whole message with all its sub-
+   parts.  A MIME entity that is the whole message includes only the
+   MIME headers and MIME body, and does not include the RFC-822 headers.
+   Note that S/MIME can also be used to secure MIME entities used in
+   applications other than Internet mail.  If protection of the RFC-822
+   headers is required, the use of the message/rfc822 MIME type is
+   explained later in this section.
+
+   The MIME entity that is secured and described in this section can be
+   thought of as the "inside" MIME entity.  That is, it is the
+   "innermost" object in what is possibly a larger MIME message.
+   Processing "outside" MIME entities into CMS content types is
+   described in Section 3.2, 3.4, and elsewhere.
+
+   The procedure for preparing a MIME entity is given in [MIME-SPEC].
+   The same procedure is used here with some additional restrictions
+
+
+
+Ramsdell                    Standards Track                    [Page 14]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+   when signing.  Description of the procedures from [MIME-SPEC] are
+   repeated here, but it is suggested that the reader refer to that
+   document for the exact procedure.  This section also describes
+   additional requirements.
+
+   A single procedure is used for creating MIME entities that are to
+   have any combination of signing, enveloping, and compressing applied.
+   Some additional steps are recommended to defend against known
+   corruptions that can occur during mail transport that are of
+   particular importance for clear-signing using the multipart/signed
+   format.  It is recommended that these additional steps be performed
+   on enveloped messages, or signed and enveloped messages, so that the
+   message can be forwarded to any environment without modification.
+
+   These steps are descriptive rather than prescriptive.  The
+   implementer is free to use any procedure as long as the result is the
+   same.
+
+   Step 1.  The MIME entity is prepared according to the local
+   conventions.
+
+   Step 2.  The leaf parts of the MIME entity are converted to canonical
+   form.
+
+   Step 3.  Appropriate transfer encoding is applied to the leaves of
+   the MIME entity.
+
+   When an S/MIME message is received, the security services on the
+   message are processed, and the result is the MIME entity.  That MIME
+   entity is typically passed to a MIME-capable user agent where, it is
+   further decoded and presented to the user or receiving application.
+
+   In order to protect outer, non-content related message headers (for
+   instance, the "Subject", "To", "From" and "CC" fields), the sending
+   client MAY wrap a full MIME message in a message/rfc822 wrapper in
+   order to apply S/MIME security services to these headers.  It is up
+   to the receiving client to decide how to present these "inner"
+   headers along with the unprotected "outer" headers.
+
+   When an S/MIME message is received, if the top-level protected MIME
+   entity has a Content-Type of message/rfc822, it can be assumed that
+   the intent was to provide header protection.  This entity SHOULD be
+   presented as the top-level message, taking into account header
+   merging issues as previously discussed.
+
+
+
+
+
+
+
+Ramsdell                    Standards Track                    [Page 15]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+3.1.1.  Canonicalization
+
+   Each MIME entity MUST be converted to a canonical form that is
+   uniquely and unambiguously representable in the environment where the
+   signature is created and the environment where the signature will be
+   verified.  MIME entities MUST be canonicalized for enveloping and
+   compressing as well as signing.
+
+   The exact details of canonicalization depend on the actual MIME type
+   and subtype of an entity, and are not described here.  Instead, the
+   standard for the particular MIME type SHOULD be consulted.  For
+   example, canonicalization of type text/plain is different from
+   canonicalization of audio/basic.  Other than text types, most types
+   have only one representation regardless of computing platform or
+   environment which can be considered their canonical representation.
+   In general, canonicalization will be performed by the non-security
+   part of the sending agent rather than the S/MIME implementation.
+
+   The most common and important canonicalization is for text, which is
+   often represented differently in different environments.  MIME
+   entities of major type "text" MUST have both their line endings and
+   character set canonicalized.  The line ending MUST be the pair of
+   characters <CR><LF>, and the charset SHOULD be a registered charset
+   [CHARSETS].  The details of the canonicalization are specified in
+   [MIME-SPEC].  The chosen charset SHOULD be named in the charset
+   parameter so that the receiving agent can unambiguously determine the
+   charset used.
+
+   Note that some charsets such as ISO-2022 have multiple
+   representations for the same characters.  When preparing such text
+   for signing, the canonical representation specified for the charset
+   MUST be used.
+
+3.1.2.  Transfer Encoding
+
+   When generating any of the secured MIME entities below, except the
+   signing using the multipart/signed format, no transfer encoding is
+   required at all.  S/MIME implementations MUST be able to deal with
+   binary MIME objects.  If no Content-Transfer-Encoding header is
+   present, the transfer encoding is presumed to be 7BIT.
+
+   S/MIME implementations SHOULD however use transfer encoding described
+   in section 3.1.3 for all MIME entities they secure.  The reason for
+   securing only 7-bit MIME entities, even for enveloped data that are
+   not exposed to the transport, is that it allows the MIME entity to be
+   handled in any environment without changing it.  For example, a
+   trusted gateway might remove the envelope, but not the signature, of
+   a message, and then forward the signed message on to the end
+
+
+
+Ramsdell                    Standards Track                    [Page 16]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+   recipient so that they can verify the signatures directly.  If the
+   transport internal to the site is not 8-bit clean, such as on a
+   wide-area network with a single mail gateway, verifying the signature
+   will not be possible unless the original MIME entity was only 7-bit
+   data.
+
+   S/MIME implementations which "know" that all intended recipient(s)
+   are capable of handling inner (all but the outermost) binary MIME
+   objects SHOULD use binary encoding as opposed to a 7-bit-safe
+   transfer encoding for the inner entities.  The use of a 7-bit-safe
+   encoding (such as base64) would unnecessarily expand the message
+   size.  Implementations MAY "know" that recipient implementations are
+   capable of handling inner binary MIME entities either by interpreting
+   the id-cap-preferBinaryInside sMIMECapabilities attribute, by prior
+   agreement, or by other means.
+
+   If one or more intended recipients are unable to handle inner binary
+   MIME objects, or if this capability is unknown for any of the
+   intended recipients, S/MIME implementations SHOULD use transfer
+   encoding described in section 3.1.3 for all MIME entities they
+   secure.
+
+3.1.3.  Transfer Encoding for Signing Using multipart/signed
+
+   If a multipart/signed entity is ever to be transmitted over the
+   standard Internet SMTP infrastructure or other transport that is
+   constrained to 7-bit text, it MUST have transfer encoding applied so
+   that it is represented as 7-bit text.  MIME entities that are 7-bit
+   data already need no transfer encoding.  Entities such as 8-bit text
+   and binary data can be encoded with quoted-printable or base-64
+   transfer encoding.
+
+   The primary reason for the 7-bit requirement is that the Internet
+   mail transport infrastructure cannot guarantee transport of 8-bit or
+   binary data.  Even though many segments of the transport
+   infrastructure now handle 8-bit and even binary data, it is sometimes
+   not possible to know whether the transport path is 8-bit clean.  If a
+   mail message with 8-bit data were to encounter a message transfer
+   agent that can not transmit 8-bit or binary data, the agent has three
+   options, none of which are acceptable for a clear-signed message:
+
+   -  The agent could change the transfer encoding; this would
+      invalidate the signature.
+   -  The agent could transmit the data anyway, which would most likely
+      result in the 8th bit being corrupted; this too would invalidate
+      the signature.
+   -  The agent could return the message to the sender.
+
+
+
+
+Ramsdell                    Standards Track                    [Page 17]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+   [MIME-SECURE] prohibits an agent from changing the transfer encoding
+   of the first part of a multipart/signed message.  If a compliant
+   agent that can not transmit 8-bit or binary data encounters a
+   multipart/signed message with 8-bit or binary data in the first part,
+   it would have to return the message to the sender as undeliverable.
+
+3.1.4.  Sample Canonical MIME Entity
+
+   This example shows a multipart/mixed message with full transfer
+   encoding.  This message contains a text part and an attachment.  The
+   sample message text includes characters that are not US-ASCII and
+   thus need to be transfer encoded.  Though not shown here, the end of
+   each line is <CR><LF>.  The line ending of the MIME headers, the
+   text, and transfer encoded parts, all MUST be <CR><LF>.
+
+   Note that this example is not of an S/MIME message.
+
+       Content-Type: multipart/mixed; boundary=bar
+
+       --bar
+       Content-Type: text/plain; charset=iso-8859-1
+       Content-Transfer-Encoding: quoted-printable
+
+       =A1Hola Michael!
+
+       How do you like the new S/MIME specification?
+
+       It's generally a good idea to encode lines that begin with
+       From=20because some mail transport agents will insert a greater-
+       than (>) sign, thus invalidating the signature.
+
+       Also, in some cases it might be desirable to encode any   =20
+       trailing whitespace that occurs on lines in order to ensure  =20
+       that the message signature is not invalidated when passing =20
+       a gateway that modifies such whitespace (like BITNET). =20
+
+       --bar
+       Content-Type: image/jpeg
+       Content-Transfer-Encoding: base64
+
+       iQCVAwUBMJrRF2N9oWBghPDJAQE9UQQAtl7LuRVndBjrk4EqYBIb3h5QXIX/LC//
+       jJV5bNvkZIGPIcEmI5iFd9boEgvpirHtIREEqLQRkYNoBActFBZmh9GC3C041WGq
+       uMbrbxc+nIs1TIKlA08rVi9ig/2Yh7LFrK5Ein57U/W72vgSxLhe/zhdfolT9Brn
+       HOxEa44b+EI=
+
+       --bar--
+
+
+
+
+
+Ramsdell                    Standards Track                    [Page 18]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+3.2.  The application/pkcs7-mime Type
+
+   The application/pkcs7-mime type is used to carry CMS content types
+   including EnvelopedData, SignedData, and CompressedData.  The details
+   of constructing these entities is described in subsequent sections.
+   This section describes the general characteristics of the
+   application/pkcs7-mime type.
+
+   The carried CMS object always contains a MIME entity that is prepared
+   as described in section 3.1 if the eContentType is id-data.  Other
+   contents MAY be carried when the eContentType contains different
+   values.  See [ESS] for an example of this with signed receipts.
+
+   Since CMS content types are binary data, in most cases base-64
+   transfer encoding is appropriate, in particular, when used with SMTP
+   transport.  The transfer encoding used depends on the transport
+   through which the object is to be sent, and is not a characteristic
+   of the MIME type.
+
+   Note that this discussion refers to the transfer encoding of the CMS
+   object or "outside" MIME entity.  It is completely distinct from, and
+   unrelated to, the transfer encoding of the MIME entity secured by the
+   CMS object, the "inside" object, which is described in section 3.1.
+
+   Because there are several types of application/pkcs7-mime objects, a
+   sending agent SHOULD do as much as possible to help a receiving agent
+   know about the contents of the object without forcing the receiving
+   agent to decode the ASN.1 for the object.  The MIME headers of all
+   application/pkcs7-mime objects SHOULD include the optional "smime-
+   type" parameter, as described in the following sections.
+
+3.2.1.  The name and filename Parameters
+
+   For the application/pkcs7-mime, sending agents SHOULD emit the
+   optional "name" parameter to the Content-Type field for compatibility
+   with older systems.  Sending agents SHOULD also emit the optional
+   Content-Disposition field [CONTDISP] with the "filename" parameter.
+   If a sending agent emits the above parameters, the value of the
+   parameters SHOULD be a file name with the appropriate extension:
+
+
+
+
+
+
+
+
+
+
+
+
+Ramsdell                    Standards Track                    [Page 19]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+   MIME Type                                            File Extension
+
+   application/pkcs7-mime (SignedData, EnvelopedData)      .p7m
+
+   application/pkcs7-mime (degenerate SignedData           .p7c
+     certificate management message)
+
+   application/pkcs7-mime (CompressedData)                 .p7z
+
+   application/pkcs7-signature (SignedData)                .p7s
+
+   In addition, the file name SHOULD be limited to eight characters
+   followed by a three letter extension.  The eight character filename
+   base can be any distinct name; the use of the filename base "smime"
+   SHOULD be used to indicate that the MIME entity is associated with
+   S/MIME.
+
+   Including a file name serves two purposes.  It facilitates easier use
+   of S/MIME objects as files on disk.  It also can convey type
+   information across gateways.  When a MIME entity of type
+   application/pkcs7-mime (for example) arrives at a gateway that has no
+   special knowledge of S/MIME, it will default the entity's MIME type
+   to application/octet-stream and treat it as a generic attachment,
+   thus losing the type information.  However, the suggested filename
+   for an attachment is often carried across a gateway.  This often
+   allows the receiving systems to determine the appropriate application
+   to hand the attachment off to, in this case, a stand-alone S/MIME
+   processing application.  Note that this mechanism is provided as a
+   convenience for implementations in certain environments.  A proper
+   S/MIME implementation MUST use the MIME types and MUST NOT rely on
+   the file extensions.
+
+3.2.2.  The smime-type parameter
+
+   The application/pkcs7-mime content type defines the optional "smime-
+   type" parameter.  The intent of this parameter is to convey details
+   about the security applied (signed or enveloped) along with
+   information about the contained content.  This specification defines
+   the following smime-types.
+
+
+
+
+
+
+
+
+
+
+
+
+Ramsdell                    Standards Track                    [Page 20]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+   Name                   CMS type                Inner Content
+
+   enveloped-data         EnvelopedData           id-data
+
+   signed-data            SignedData              id-data
+
+   certs-only             SignedData              none
+
+   compressed-data        CompressedData          id-data
+
+   In order for consistency to be obtained with future specifications,
+   the following guidelines SHOULD be followed when assigning a new
+   smime-type parameter.
+
+   1. If both signing and encryption can be applied to the content, then
+   two values for smime-type SHOULD be assigned "signed-*" and
+   "encrypted-*".  If one operation can be assigned then this can be
+   omitted.  Thus since "certs-only" can only be signed, "signed-" is
+   omitted.
+
+   2. A common string for a content OID SHOULD be assigned.  We use
+   "data" for the id-data content OID when MIME is the inner content.
+
+   3. If no common string is assigned.  Then the common string of
+   "OID.<oid>" is recommended (for example, "OID.1.3.6.1.5.5.7.6.1"
+   would be DES40).
+
+   It is explicitly intended that this field be a suitable hint for mail
+   client applications to indicate whether a message is "signed" or
+   "encrypted" without having to tunnel into the CMS payload.
+
+3.3.  Creating an Enveloped-only Message
+
+   This section describes the format for enveloping a MIME entity
+   without signing it.  It is important to note that sending enveloped
+   but not signed messages does not provide for data integrity.  It is
+   possible to replace ciphertext in such a way that the processed
+   message will still be valid, but the meaning can be altered.
+
+   Step 1.  The MIME entity to be enveloped is prepared according to
+   section 3.1.
+
+   Step 2.  The MIME entity and other required data is processed into a
+   CMS object of type EnvelopedData.  In addition to encrypting a copy
+   of the content-encryption key for each recipient, a copy of the
+   content-encryption key SHOULD be encrypted for the originator and
+   included in the EnvelopedData (see [CMS] Section 6).
+
+
+
+
+Ramsdell                    Standards Track                    [Page 21]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+   Step 3.  The EnvelopedData object is wrapped in a CMS ContentInfo
+   object.
+
+   Step 4.  The ContentInfo object is inserted into an
+   application/pkcs7-mime MIME entity.
+
+   The smime-type parameter for enveloped-only messages is "enveloped-
+   data".  The file extension for this type of message is ".p7m".
+
+   A sample message would be:
+
+       Content-Type: application/pkcs7-mime; smime-type=enveloped-data;
+            name=smime.p7m
+       Content-Transfer-Encoding: base64
+       Content-Disposition: attachment; filename=smime.p7m
+
+       rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
+       7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
+       f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
+       0GhIGfHfQbnj756YT64V
+
+3.4.  Creating a Signed-only Message
+
+   There are two formats for signed messages defined for S/MIME:
+   application/pkcs7-mime with SignedData, and multipart/signed.  In
+   general, the multipart/signed form is preferred for sending, and
+   receiving agents MUST be able to handle both.
+
+3.4.1.  Choosing a Format for Signed-only Messages
+
+   There are no hard-and-fast rules when a particular signed-only format
+   is chosen because it depends on the capabilities of all the receivers
+   and the relative importance of receivers with S/MIME facilities being
+   able to verify the signature versus the importance of receivers
+   without S/MIME software being able to view the message.
+
+   Messages signed using the multipart/signed format can always be
+   viewed by the receiver whether they have S/MIME software or not.
+   They can also be viewed whether they are using a MIME-native user
+   agent or they have messages translated by a gateway.  In this
+   context, "be viewed" means the ability to process the message
+   essentially as if it were not a signed message, including any other
+   MIME structure the message might have.
+
+
+
+
+
+
+
+
+Ramsdell                    Standards Track                    [Page 22]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+   Messages signed using the SignedData format cannot be viewed by a
+   recipient unless they have S/MIME facilities.  However, the
+   SignedData format protects the message content from being changed by
+   benign intermediate agents.  Such agents might do line wrapping or
+   content-transfer encoding changes which would break the signature.
+
+3.4.2.  Signing Using application/pkcs7-mime with SignedData
+
+   This signing format uses the application/pkcs7-mime MIME type.  The
+   steps to create this format are:
+
+   Step 1.  The MIME entity is prepared according to section 3.1.
+
+   Step 2.  The MIME entity and other required data is processed into a
+   CMS object of type SignedData.
+
+   Step 3.  The SignedData object is wrapped in a CMS ContentInfo
+   object.
+
+   Step 4.  The ContentInfo object is inserted into an
+   application/pkcs7-mime MIME entity.
+
+   The smime-type parameter for messages using application/pkcs7-mime
+   with SignedData is "signed-data".  The file extension for this type
+   of message is ".p7m".
+
+   A sample message would be:
+
+       Content-Type: application/pkcs7-mime; smime-type=signed-data;
+            name=smime.p7m
+       Content-Transfer-Encoding: base64
+       Content-Disposition: attachment; filename=smime.p7m
+
+       567GhIGfHfYT6ghyHhHUujpfyF4f8HHGTrfvhJhjH776tbB9HG4VQbnj7
+       77n8HHGT9HG4VQpfyF467GhIGfHfYT6rfvbnj756tbBghyHhHUujhJhjH
+       HUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H7n8HHGghyHh
+       6YT64V0GhIGfHfQbnj75
+
+3.4.3.  Signing Using the multipart/signed Format
+
+   This format is a clear-signing format.  Recipients without any S/MIME
+   or CMS processing facilities are able to view the message.  It makes
+   use of the multipart/signed MIME type described in [MIME-SECURE].
+   The multipart/signed MIME type has two parts.  The first part
+   contains the MIME entity that is signed; the second part contains the
+   "detached signature" CMS SignedData object in which the
+   encapContentInfo eContent field is absent.
+
+
+
+
+Ramsdell                    Standards Track                    [Page 23]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+3.4.3.1.  The application/pkcs7-signature MIME Type
+
+   This MIME type always contains a CMS ContentInfo containing a single
+   CMS object of type SignedData.  The SignedData encapContentInfo
+   eContent field MUST be absent.  The signerInfos field contains the
+   signatures for the MIME entity.
+
+   The file extension for signed-only messages using application/pkcs7-
+   signature is ".p7s".
+
+3.4.3.2.  Creating a multipart/signed Message
+
+   Step 1.  The MIME entity to be signed is prepared according to
+   section 3.1, taking special care for clear-signing.
+
+   Step 2.  The MIME entity is presented to CMS processing in order to
+   obtain an object of type SignedData in which the encapContentInfo
+   eContent field is absent.
+
+   Step 3.  The MIME entity is inserted into the first part of a
+   multipart/signed message with no processing other than that described
+   in section 3.1.
+
+   Step 4.  Transfer encoding is applied to the "detached signature" CMS
+   SignedData object and it is inserted into a MIME entity of type
+   application/pkcs7-signature.
+
+   Step 5.  The MIME entity of the application/pkcs7-signature is
+   inserted into the second part of the multipart/signed entity.
+
+   The multipart/signed Content type has two required parameters: the
+   protocol parameter and the micalg parameter.
+
+   The protocol parameter MUST be "application/pkcs7-signature".  Note
+   that quotation marks are required around the protocol parameter
+   because MIME requires that the "/" character in the parameter value
+   MUST be quoted.
+
+   The micalg parameter allows for one-pass processing when the
+   signature is being verified.  The value of the micalg parameter is
+   dependent on the message digest algorithm(s) used in the calculation
+   of the Message Integrity Check.  If multiple message digest
+   algorithms are used they MUST be separated by commas per [MIME-
+   SECURE].  The values to be placed in the micalg parameter SHOULD be
+   from the following:
+
+
+
+
+
+
+Ramsdell                    Standards Track                    [Page 24]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+   Algorithm   Value
+   used
+
+   MD5         md5
+   SHA-1       sha1
+   SHA-256     sha256
+   SHA-384     sha384
+   SHA-512     sha512
+   Any other   (defined separately in algorithm profile or "unknown"
+                if not defined)
+
+   (Historical note: some early implementations of S/MIME emitted and
+   expected "rsa-md5" and "rsa-sha1" for the micalg parameter.)
+   Receiving agents SHOULD be able to recover gracefully from a micalg
+   parameter value that they do not recognize.
+
+   The SHA-256, SHA-384, and SHA-512 algorithms [FIPS180-2] are not
+   currently recommended in S/MIME, and are included here for
+   completeness.
+
+3.4.3.3.  Sample multipart/signed Message
+
+       Content-Type: multipart/signed;
+          protocol="application/pkcs7-signature";
+          micalg=sha1; boundary=boundary42
+
+       --boundary42
+       Content-Type: text/plain
+
+       This is a clear-signed message.
+
+       --boundary42
+       Content-Type: application/pkcs7-signature; name=smime.p7s
+       Content-Transfer-Encoding: base64
+       Content-Disposition: attachment; filename=smime.p7s
+
+       ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6
+       4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj
+       n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
+       7GhIGfHfYT64VQbnj756
+
+       --boundary42--
+
+
+
+
+
+
+
+
+
+Ramsdell                    Standards Track                    [Page 25]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+   The content that is digested (the first part of the multipart/signed)
+   are the bytes:
+
+   43 6f 6e 74 65 6e 74 2d 54 79 70 65 3a 20 74 65 78 74 2f 70 6c 61 69
+   6e 0d 0a 0d 0a 54 68 69 73 20 69 73 20 61 20 63 6c 65 61 72 2d 73 69
+   67 6e 65 64 20 6d 65 73 73 61 67 65 2e 0d 0a
+
+3.5.  Creating an Compressed-only Message
+
+   This section describes the format for compressing a MIME entity.
+   Please note that versions of S/MIME prior to 3.1 did not specify any
+   use of CompressedData, and will not recognize it.  The use of a
+   capability to indicate the ability to receive CompressedData is
+   described in [CMSCOMPR] and is the preferred method for
+   compatibility.
+
+   Step 1.  The MIME entity to be compressed is prepared according to
+   section 3.1.
+
+   Step 2.  The MIME entity and other required data is processed into a
+   CMS object of type CompressedData.
+
+   Step 3.  The CompressedData object is wrapped in a CMS ContentInfo
+   object.
+
+   Step 4.  The ContentInfo object is inserted into an
+   application/pkcs7-mime MIME entity.
+
+   The smime-type parameter for compressed-only messages is
+   "compressed-data".  The file extension for this type of message is
+   ".p7z".
+
+   A sample message would be:
+
+       Content-Type: application/pkcs7-mime; smime-type=compressed-data;
+            name=smime.p7z
+       Content-Transfer-Encoding: base64
+       Content-Disposition: attachment; filename=smime.p7z
+
+       rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
+       7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
+       f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
+       0GhIGfHfQbnj756YT64V
+
+
+
+
+
+
+
+
+Ramsdell                    Standards Track                    [Page 26]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+3.6.  Multiple Operations
+
+   The signed-only, encrypted-only, and compressed-only MIME formats can
+   be nested.  This works because these formats are all MIME entities
+   that encapsulate other MIME entities.
+
+   An S/MIME implementation MUST be able to receive and process
+   arbitrarily nested S/MIME within reasonable resource limits of the
+   recipient computer.
+
+   It is possible to apply any of the signing, encrypting, and
+   compressing operations in any order.  It is up to the implementer and
+   the user to choose.  When signing first, the signatories are then
+   securely obscured by the enveloping.  When enveloping first the
+   signatories are exposed, but it is possible to verify signatures
+   without removing the enveloping.  This can be useful in an
+   environment were automatic signature verification is desired, as no
+   private key material is required to verify a signature.
+
+   There are security ramifications to choosing whether to sign first or
+   encrypt first.  A recipient of a message that is encrypted and then
+   signed can validate that the encrypted block was unaltered, but
+   cannot determine any relationship between the signer and the
+   unencrypted contents of the message.  A recipient of a message that
+   is signed-then-encrypted can assume that the signed message itself
+   has not been altered, but that a careful attacker could have changed
+   the unauthenticated portions of the encrypted message.
+
+   When using compression, keep the following guidelines in mind:
+
+   -  Compression of binary encoded encrypted data is discouraged, since
+      it will not yield significant compression.  Base64 encrypted data
+      could very well benefit, however.
+   -  If a lossy compression algorithm is used with signing, you will
+      need to compress first, then sign.
+
+3.7.  Creating a Certificate Management Message
+
+   The certificate management message or MIME entity is used to
+   transport certificates and/or certificate revocation lists, such as
+   in response to a registration request.
+
+   Step 1.  The certificates and/or certificate revocation lists are
+   made available to the CMS generating process which creates a CMS
+   object of type SignedData.  The SignedData encapContentInfo eContent
+   field MUST be absent and signerInfos field MUST be empty.
+
+
+
+
+
+Ramsdell                    Standards Track                    [Page 27]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+   Step 2.  The SignedData object is wrapped in a CMS ContentInfo
+   object.
+
+   Step 3.  The ContentInfo object is enclosed in an application/pkcs7-
+   mime MIME entity.
+
+   The smime-type parameter for a certificate management message is
+   "certs-only".  The file extension for this type of message is ".p7c".
+
+3.8.  Registration Requests
+
+   A sending agent that signs messages MUST have a certificate for the
+   signature so that a receiving agent can verify the signature.  There
+   are many ways of getting certificates, such as through an exchange
+   with a certificate authority, through a hardware token or diskette,
+   and so on.
+
+   S/MIME v2 [SMIMEV2] specified a method for "registering" public keys
+   with certificate authorities using an application/pkcs10 body part.
+   Since that time, the IETF PKIX Working Group has developed other
+   methods for requesting certificates.  However, S/MIME v3.1 does not
+   require a particular certificate request mechanism.
+
+3.9.  Identifying an S/MIME Message
+
+   Because S/MIME takes into account interoperation in non-MIME
+   environments, several different mechanisms are employed to carry the
+   type information, and it becomes a bit difficult to identify S/MIME
+   messages.  The following table lists criteria for determining whether
+   or not a message is an S/MIME message.  A message is considered an
+   S/MIME message if it matches any of the criteria listed below.
+
+   The file suffix in the table below comes from the "name" parameter in
+   the content-type header, or the "filename" parameter on the content-
+   disposition header.  These parameters that give the file suffix are
+   not listed below as part of the parameter section.
+
+   MIME type:   application/pkcs7-mime
+   parameters:  any
+   file suffix: any
+
+   MIME type:   multipart/signed
+   parameters:  protocol="application/pkcs7-signature"
+   file suffix: any
+
+   MIME type:   application/octet-stream
+   parameters:  any
+   file suffix: p7m, p7s, p7c, p7z
+
+
+
+Ramsdell                    Standards Track                    [Page 28]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+4.  Certificate Processing
+
+   A receiving agent MUST provide some certificate retrieval mechanism
+   in order to gain access to certificates for recipients of digital
+   envelopes.  This specification does not cover how S/MIME agents
+   handle certificates, only what they do after a certificate has been
+   validated or rejected.  S/MIME certificate issues are covered in
+   [CERT31].
+
+   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.
+
+4.1.  Key Pair Generation
+
+   All generated key pairs MUST be generated from a good source of non-
+   deterministic random input [RANDOM] and the private key MUST be
+   protected in a secure fashion.
+
+   If an S/MIME agent needs to generate an RSA key pair, then the S/MIME
+   agent or some related administrative utility or function SHOULD
+   generate RSA key pairs using the following guidelines.  A user agent
+   SHOULD generate RSA key pairs at a minimum key size of 768 bits.  A
+   user agent MUST NOT generate RSA key pairs less than 512 bits long.
+   Creating keys longer than 1024 bits can cause some older S/MIME
+   receiving agents to not be able to verify signatures, but gives
+   better security and is therefore valuable.  A receiving agent SHOULD
+   be able to verify signatures with keys of any size over 512 bits.
+   Some agents created in the United States have chosen to create 512
+   bit keys in order to get more advantageous export licenses.  However,
+   512 bit keys are considered by many to be cryptographically insecure.
+   Implementers SHOULD be aware that multiple (active) key pairs can be
+   associated with a single individual.  For example, one key pair can
+   be used to support confidentiality, while a different key pair can be
+   used for authentication.
+
+5.  Security Considerations
+
+   40-bit encryption is considered weak by most cryptographers.  Using
+   weak cryptography in S/MIME offers little actual security over
+   sending plaintext.  However, other features of S/MIME, such as the
+   specification of tripleDES and the ability to announce stronger
+   cryptographic capabilities to parties with whom you communicate,
+   allow senders to create messages that use strong encryption.  Using
+   weak cryptography is never recommended unless the only alternative is
+
+
+
+Ramsdell                    Standards Track                    [Page 29]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+   no cryptography.  When feasible, sending and receiving agents SHOULD
+   inform senders and recipients of the relative cryptographic strength
+   of messages.
+
+   It is impossible for most software or people to estimate the value of
+   a message.  Further, it is impossible for most software or people to
+   estimate the actual cost of decrypting a message that is encrypted
+   with a key of a particular size.  Further, it is quite difficult to
+   determine the cost of a failed decryption if a recipient cannot
+   decode a message.  Thus, choosing between different key sizes (or
+   choosing whether to just use plaintext) is also impossible.  However,
+   decisions based on these criteria are made all the time, and
+   therefore this specification gives a framework for using those
+   estimates in choosing algorithms.
+
+   If a sending agent is sending the same message using different
+   strengths of cryptography, an attacker watching the communications
+   channel might be able to determine the contents of the strongly-
+   encrypted message by decrypting the weakly-encrypted version.  In
+   other words, a sender SHOULD NOT send a copy of a message using
+   weaker cryptography than they would use for the original of the
+   message.
+
+   Modification of the ciphertext can go undetected if authentication is
+   not also used, which is the case when sending EnvelopedData without
+   wrapping it in SignedData or enclosing SignedData within it.
+
+   See RFC 3218 [MMA] for more information about thwarting the adaptive
+   chosen ciphertext vulnerability in PKCS #1 Version 1.5
+   implementations.
+
+   In some circumstances the use of the Diffie-Hellman key agreement
+   scheme in a prime order subgroup of a large prime p is vulnerable to
+   certain attacks known as "small-subgroup" attacks.  Methods exist,
+   however, to prevent these attacks.  These methods are described in
+   RFC 2785 [DHSUB].
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ramsdell                    Standards Track                    [Page 30]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+A.  ASN.1 Module
+
+SecureMimeMessageV3dot1
+  { iso(1) member-body(2) us(840) rsadsi(113549)
+         pkcs(1) pkcs-9(9) smime(16) modules(0) msg-v3dot1(21) }
+
+DEFINITIONS IMPLICIT TAGS ::=
+BEGIN
+
+IMPORTS
+-- Cryptographic Message Syntax
+    SubjectKeyIdentifier, IssuerAndSerialNumber,
+    RecipientKeyIdentifier
+        FROM    CryptographicMessageSyntax
+               { iso(1) member-body(2) us(840) rsadsi(113549)
+                 pkcs(1) pkcs-9(9) smime(16) modules(0) cms-2001(14) };
+
+
+--  id-aa is the arc with all new authenticated and unauthenticated
+--  attributes produced the by S/MIME Working Group
+
+id-aa OBJECT IDENTIFIER ::= {iso(1) member-body(2) usa(840)
+        rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) attributes(2)}
+
+-- S/MIME Capabilities provides a method of broadcasting the symmetric
+-- capabilities understood.  Algorithms SHOULD be ordered by
+-- preference and grouped by type
+
+smimeCapabilities OBJECT IDENTIFIER ::=
+   {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15}
+
+SMIMECapability ::= SEQUENCE {
+   capabilityID OBJECT IDENTIFIER,
+   parameters ANY DEFINED BY capabilityID OPTIONAL }
+
+SMIMECapabilities ::= SEQUENCE OF SMIMECapability
+
+-- Encryption Key Preference provides a method of broadcasting the
+-- preferred encryption certificate.
+
+id-aa-encrypKeyPref OBJECT IDENTIFIER ::= {id-aa 11}
+
+SMIMEEncryptionKeyPreference ::= CHOICE {
+   issuerAndSerialNumber   [0] IssuerAndSerialNumber,
+   receipentKeyId          [1] RecipientKeyIdentifier,
+   subjectAltKeyIdentifier [2] SubjectKeyIdentifier
+}
+
+
+
+
+Ramsdell                    Standards Track                    [Page 31]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+id-smime OBJECT IDENTIFIER ::= { iso(1) member-body(2)
+   us(840) rsadsi(113549) pkcs(1) pkcs9(9) 16 }
+
+id-cap  OBJECT IDENTIFIER ::= { id-smime 11 }
+
+-- The preferBinaryInside indicates an ability to receive messages
+-- with binary encoding inside the CMS wrapper
+
+id-cap-preferBinaryInside  OBJECT IDENTIFIER ::= { id-cap 1 }
+
+--  The following list the OIDs to be used with S/MIME V3
+
+-- Signature Algorithms Not Found in [CMSALG]
+--
+-- md2WithRSAEncryption OBJECT IDENTIFIER ::=
+--    {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1)
+--     2}
+--
+-- Other Signed Attributes
+--
+-- signingTime OBJECT IDENTIFIER ::=
+--    {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9)
+--     5}
+--    See [CMS] for a description of how to encode the attribute
+--    value.
+
+SMIMECapabilitiesParametersForRC2CBC ::= INTEGER
+--        (RC2 Key Length (number of bits))
+
+END
+
+B.  References
+
+B.1.  Normative References
+
+   [CERT31]      Ramsdell, B., Ed., "S/MIME Version 3.1 Certificate
+                 Handling", RFC 3850, July 2004.
+
+   [CHARSETS]    Character sets assigned by IANA.  See
+                 http://www.iana.org/assignments/character-sets
+
+   [CMS]         Housley, R., "Cryptographic Message Syntax (CMS)", RFC
+                 3852, July 2004.
+
+   [CMSAES]      Schaad, J., "Use of the Advanced Encryption Standard
+                 (AES) Encryption Algorithm in Cryptographic Message
+                 Syntax (CMS)", RFC 3565, July 2003.
+
+
+
+
+Ramsdell                    Standards Track                    [Page 32]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+   [CMSALG]      Housley, R., "Cryptographic Message Syntax (CMS)
+                 Algorithms", RFC 3370, August 2002.
+
+   [CMSCOMPR]    Gutmann, P., "Compressed Data Content Type for
+                 Cryptographic Message Syntax (CMS)", RFC 3274, June
+                 2002.
+
+   [CONTDISP]    Troost, R., Dorner, S., and K. Moore, "Communicating
+                 Presentation Information in Internet Messages: The
+                 Content-Disposition Header Field", RFC 2183, August
+                 1997.
+
+   [ESS]         Hoffman, P., "Enhanced Security Services for S/MIME",
+                 RFC 2634, June 1999.
+
+   [FIPS180-2]   "Secure Hash Signature Standard (SHS)", National
+                 Institute of Standards and Technology (NIST).  FIPS
+                 Publication 180-2.
+
+   [MIME-SPEC]   Freed, N. and N. Borenstein, "Multipurpose Internet
+                 Mail Extensions (MIME) Part One: Format of Internet
+                 Message Bodies", RFC 2045, November 1996.
+
+                 Freed, N. and N. Borenstein, "Multipurpose Internet
+                 Mail Extensions (MIME) Part Two: Media Types", RFC
+                 2046, November 1996.
+
+                 Moore, K., "MIME (Multipurpose Internet Mail
+                 Extensions) Part Three:  Message Header Extensions for
+                 Non-ASCII Text", RFC 2047, November 1996.
+
+                 Freed, N., Klensin, J., and J. Postel, "Multipurpose
+                 Internet Mail Extensions (MIME) Part Four: Registration
+                 Procedures", BCP 13, RFC 2048, November 1996.
+
+                 Freed, N. and N. Borenstein, "Multipurpose Internet
+                 Mail Extensions (MIME) Part Five: Conformance Criteria
+                 and Examples", RFC 2049, November 1996.
+
+   [MIME-SECURE] Galvin, J., Murphy, S., Crocker, S., and N. Freed,
+                 "Security Multiparts for MIME: Multipart/Signed and
+                 Multipart/Encrypted", RFC 1847, October 1995.
+
+   [MUSTSHOULD]  Bradner, S., "Key words for use in RFCs to Indicate
+                 Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [X.208-88]    CCITT.  Recommendation X.208: Specification of Abstract
+                 Syntax Notation One (ASN.1).  1988.
+
+
+
+Ramsdell                    Standards Track                    [Page 33]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+   [X.209-88]    CCITT.  Recommendation X.209: Specification of Basic
+                 Encoding Rules for Abstract Syntax Notation One
+                 (ASN.1).  1988.
+
+   [X.509-88]    CCITT.  Recommendation X.509: The Directory -
+                 Authentication Framework.  1988.
+
+B.2.  Informative References
+
+   [DHSUB]       Zuccherato, R., "Methods for Avoiding the "Small-
+                 Subgroup" Attacks on the Diffie-Hellman Key Agreement
+                 Method for S/MIME", RFC 2785, March 2000.
+
+   [MMA]         Rescorla, E., "Preventing the Million Message Attack on
+                 Cryptographic Message Syntax", RFC 3218, January 2002.
+
+   [PKCS-7]      Kaliski, B., "PKCS #7: Cryptographic Message Syntax
+                 Version 1.5", RFC 2315, March 1998.
+
+   [RANDOM]      Eastlake 3rd, D., Crocker, S., and J. Schiller,
+                 "Randomness Recommendations for Security", RFC 1750,
+                 December 1994.
+
+   [SMIMEV2]     Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L.,
+                 and L. Repka, "S/MIME Version 2 Message Specification",
+                 RFC 2311, March 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ramsdell                    Standards Track                    [Page 34]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+C.  Acknowledgements
+
+   Many thanks go out to the other authors of the S/MIME Version 2
+   Message Specification RFC: Steve Dusse, Paul Hoffman, Laurence
+   Lundblade and Lisa Repka.
+
+   A number of the members of the S/MIME Working Group have also worked
+   very hard and contributed to this document.  Any list of people is
+   doomed to omission, and for that I apologize.  In alphabetical order,
+   the following people stand out in my mind due to the fact that they
+   made direct contributions to this document.
+
+   Tony Capel
+   Piers Chivers
+   Dave Crocker
+   Bill Flanigan
+   Peter Gutmann
+   Paul Hoffman
+   Russ Housley
+   William Ottaway
+   John Pawling
+   Jim Schaad
+
+D.  Editor's Address
+
+   Blake Ramsdell
+   Sendmail, Inc.
+   704 228th Ave NE #775
+   Sammamish, WA  98074
+
+   EMail: blake@sendmail.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Ramsdell                    Standards Track                    [Page 35]
+
+RFC 3851            S/MIME 3.1 Message Specification           July 2004
+
+
+Full Copyright Statement
+
+   Copyright (C) The Internet Society (2004).  This document is subject
+   to the rights, licenses and restrictions contained in BCP 78, and
+   except as set forth therein, the authors retain all their rights.
+
+   This document and the information contained herein are provided on an
+   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
+   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
+   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
+   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Intellectual Property
+
+   The IETF takes no position regarding the validity or scope of any
+   Intellectual Property Rights or other rights that might be claimed to
+   pertain to the implementation or use of the technology described in
+   this document or the extent to which any license under such rights
+   might or might not be available; nor does it represent that it has
+   made any independent effort to identify any such rights.  Information
+   on the procedures with respect to rights in RFC documents can be
+   found in BCP 78 and BCP 79.
+
+   Copies of IPR disclosures made to the IETF Secretariat and any
+   assurances of licenses to be made available, or the result of an
+   attempt made to obtain a general license or permission for the use of
+   such proprietary rights by implementers or users of this
+   specification can be obtained from the IETF on-line IPR repository at
+   http://www.ietf.org/ipr.
+
+   The IETF invites any interested party to bring to its attention any
+   copyrights, patents or patent applications, or other proprietary
+   rights that may cover technology that may be required to implement
+   this standard.  Please address the information to the IETF at ietf-
+   ipr@ietf.org.
+
+Acknowledgement
+
+   Funding for the RFC Editor function is currently provided by the
+   Internet Society.
+
+
+
+
+
+
+
+
+
+Ramsdell                    Standards Track                    [Page 36]
+