doc: Add RFC documents

1 files changed, 2075 insertions, 0 deletions

diff --git a/doc/rfc/rfc2311.txt b/doc/rfc/rfc2311.txt
new file mode 100644
index 0000000..cf0ab5d
--- /dev/null
+++ b/doc/rfc/rfc2311.txt
@@ -0,0 +1,2075 @@
+
+
+
+
+
+
+Network Working Group                                          S. Dusse
+Request for Comments: 2311                            RSA Data Security
+Category: Informational                                      P. Hoffman
+                                               Internet Mail Consortium
+                                                            B. Ramsdell
+                                                              Worldtalk
+                                                           L. Lundblade
+                                                               Qualcomm
+                                                               L. Repka
+                                                               Netscape
+                                                             March 1998
+
+
+                 S/MIME Version 2 Message Specification
+
+Status of this Memo
+
+   This memo provides information for the Internet community.  It does
+   not specify an Internet standard of any kind.  Distribution of this
+   memo is unlimited.
+
+Copyright Notice
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+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 privacy and data security
+   (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.
+
+
+
+
+Dusse, et. al.               Informational                      [Page 1]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+   Please note: The information in this document is historical material
+   being published for the public record. It is not an IETF standard.
+   The use of the word "standard" in this document indicates a standard
+   for adopters of S/MIME version 2, not an IETF standard.
+
+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 memo defines how to create a MIME body part that has been
+   cryptographically enhanced according to PKCS #7 [PKCS-7]. This memo
+   also defines the application/pkcs7-mime MIME type that can be used to
+   transport those body parts. This memo also defines how to create
+   certification requests that conform to PKCS #10 [PKCS-10], and the
+   application/pkcs10 MIME type for transporting those requests.
+
+   This memo also discusses how to use the multipart/signed MIME type
+   defined in [MIME-SECURE] to transport S/MIME signed messages. This
+   memo also defines the application/pkcs7-signature MIME type, which is
+   also used to transport S/MIME signed messages. This specification is
+   compatible with PKCS #7 in that it uses the data types defined by
+   PKCS #7.
+
+   In order to create S/MIME messages, an agent has to follow
+   specifications in this memo, as well as some of the specifications
+   listed in the following documents:
+
+    - "PKCS #1: RSA Encryption", [PKCS-1]
+    - "PKCS #7: Cryptographic Message Syntax", [PKCS-7]
+    - "PKCS #10: Certification Request Syntax", [PKCS-10]
+
+   Throughout this memo, 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
+
+
+
+
+
+Dusse, et. al.               Informational                      [Page 2]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+   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
+
+   Throughout this memo, the terms MUST, MUST NOT, SHOULD, and SHOULD
+   NOT are used in capital letters. This conforms to the definitions in
+   [MUSTSHOULD].  [MUSTSHOULD] defines the use of these key words to
+   help make the intent of standards track documents as clear as
+   possible. The same key words are used in this document to help
+   implementors achieve interoperability.
+
+1.3 Definitions
+
+   For the purposes of this memo, 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.
+
+   DER: Distinguished Encoding Rules for ASN.1, as defined in CCITT
+   X.509.
+
+   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 may be sent via a channel that only transmits 7-bit
+   data.
+
+1.4 Compatibility with Prior Practice of S/MIME
+
+   Appendix C contains important information about how S/MIME agents
+   following this specification should act in order to have the greatest
+   interoperability with earlier implementations of S/MIME.
+
+
+
+Dusse, et. al.               Informational                      [Page 3]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+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.
+
+2.1 DigestAlgorithmIdentifier
+
+   Receiving agents MUST support SHA-1 [SHA1] and MD5 [MD5].
+
+   Sending agents SHOULD use SHA-1.
+
+2.2 DigestEncryptionAlgorithmIdentifier
+
+   Receiving agents MUST support rsaEncryption, defined in [PKCS-1].
+   Receiving agents MUST support verification of signatures using RSA
+   public key sizes from 512 bits to 1024 bits.
+
+   Sending agents MUST support rsaEncryption. Outgoing messages are
+   signed with a user's private key. The size of the private key is
+   determined during key generation.
+
+2.3 KeyEncryptionAlgorithmIdentifier
+
+   Receiving agents MUST support rsaEncryption. Incoming encrypted
+   messages contain symmetric keys which are to be decrypted with a
+   user's private key.  The size of the private key is determined during
+   key generation.
+
+   Sending agents MUST support rsaEncryption. Sending agents MUST
+   support encryption of symmetric keys with RSA public keys at key
+   sizes from 512 bits to 1024 bits.
+
+2.4 General Syntax
+
+   The PKCS #7 defines six distinct content types: "data", "signedData",
+   "envelopedData", "signedAndEnvelopedData", "digestedData", and
+   "encryptedData". Receiving agents MUST support the "data",
+   "signedData" and "envelopedData" content types. Sending agents may or
+   may not send out any of the content types, depending on the services
+   that the agent supports.
+
+2.4.1 Data Content Type
+
+   Sending agents MUST use the "data" content type as the content within
+   other content types to indicate the message content which has had
+   security services applied to it.
+
+
+
+Dusse, et. al.               Informational                      [Page 4]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+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.
+
+2.4.3 EnvelopedData Content Type
+
+   This content type is used to apply privacy protection to a message. A
+   sender needs to have access to a public key for each intended message
+   recipient to use this service. This content type does not provide
+   authentication.
+
+2.5 Attribute SignerInfo Type
+
+   The SignerInfo type allows the inclusion of unauthenticated and
+   authenticated 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 described in this section.
+
+   Sending agents SHOULD be able to generate one instance of each of the
+   signed attributes described in this section, and SHOULD include these
+   attributes in each signed message sent.
+
+   Additional attributes and values for these attributes may be defined
+   in the future. Receiving agents SHOULD handle attributes or values
+   that it does not recognize in a graceful manner.
+
+2.5.1 Signing-Time Attribute
+
+   The signing-time attribute is used to convey the time that a message
+   was signed. Until there are trusted timestamping services, 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. 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 S/MIME Capabilities Attribute
+
+   The S/MIME capabilities attribute includes signature algorithms (such
+   as "md5WithRSAEncryption"), symmetric algorithms (such as "DES-CBC"),
+   and key encipherment algorithms (such as "rsaEncryption"). It also
+
+
+
+Dusse, et. al.               Informational                      [Page 5]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+   includes a non-algorithm capability which is the preference for
+   signedData.  SMIMECapabilities was 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.
+
+   The semantics of the S/MIME capabilites attribute specify a partial
+   list as to what the client announcing the SMIMECapabilites can
+   support. A client does not have to list every capability it supports,
+   and probably should not list all its capabilities so that the
+   capabilities list doesn't get too long. In an SMIMECapabilities
+   encoding, the OIDs are listed in order of their preference, but
+   SHOULD be logically separated along the lines of their categories
+   (signature algorithms, symmetric algorithms, key encipherment
+   algorithms, etc.)
+
+   The structure of  SMIMECapabilities was designed 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.
+
+   In the case of symmetric algorithms, 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 block size for RC5 must be specified in addition to the
+   key length.
+
+   There is a list of OIDs (the registered SMIMECapability list) that is
+   centrally maintained and is separate from this memo. The list of OIDs
+   is maintained by the Internet Mail Consortium at
+   <http://www.imc.org/ietf-smime/oids.html>.
+
+   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 memo,
+   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 S/MIME capabilities 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 S/MIME capabilities 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.
+
+
+
+
+Dusse, et. al.               Informational                      [Page 6]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+   Additional values for SMIMECapability may be defined in the future.
+   Receiving agents MUST handle a SMIMECapabilities object that has
+   values that it does not recognize in a graceful manner.
+
+2.6 ContentEncryptionAlgorithmIdentifier
+
+   Receiving agents MUST support decryption using the RC2 [RC2] or a
+   compatible algorithm at a key size of 40 bits, hereinafter called
+   "RC2/40".  Receiving agents SHOULD support decryption using DES EDE3
+   CBC, hereinafter called "tripleDES" [3DES] [DES].
+
+   Sending agents SHOULD support encryption with RC2/40 and tripleDES.
+
+2.6.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 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 capabilitie lists 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
+
+
+
+Dusse, et. al.               Informational                      [Page 7]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+   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.6.2.1 through 2.6.2.4 describe the decisions a sending
+   agent SHOULD use in deciding which type of encryption should be
+   applied to a message. These rules are ordered, so the sending agent
+   SHOULD make its decision in the order given.
+
+2.6.2.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) for which 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.6.2.2 Rule 2: Unknown Capabilities, Known Use of Encryption
+
+   If:
+    - the sending agent has no knowledge of the encryption capabilities
+      of the recipient,
+    - and the sending agent has received at least one message from the
+      recipient,
+    - and the last encrypted message received from the recipient had a
+      trusted signature on it,
+   then the outgoing message SHOULD use the same encryption algorithm as
+   was used on the last signed and encrypted message received from the
+   recipient.
+
+2.6.2.3 Rule 3: Unknown Capabilities, Risk of Failed Decryption
+
+   If:
+    - the sending agent has no knowledge of the encryption capabilities
+      of the recipient,
+    - and the sending agent is willing to risk that the recipient may
+      not be able to decrypt the message,
+   then the sending agent SHOULD use tripleDES.
+
+
+
+
+
+
+
+
+Dusse, et. al.               Informational                      [Page 8]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+2.6.2.4 Rule 4: Unknown Capabilities, No Risk of Failed Decryption
+
+   If:
+    - the sending agent has no knowledge of the encryption capabilities
+      of the recipient,
+    - and the sending agent is not willing to risk that the recipient
+      may not be able to decrypt the message,
+   then the sending agent MUST use RC2/40.
+
+2.6.3 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.6.4 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. It should be noted that if the sending agent
+   chooses to send a message encrypted with a strong algorithm, and then
+   send the same message encrypted with a weak algorithm, someone
+   watching the communications channel can decipher 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 PKCS
+   objects. Several MIME types as well as several PKCS objects 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 PKCS processing facilities which produces a
+   PKCS object. The PKCS object is then finally wrapped in MIME.
+
+   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].
+
+
+
+Dusse, et. al.               Informational                      [Page 9]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+3.1 Preparing the MIME Entity for Signing or Enveloping
+
+   S/MIME is used to secure MIME entities. A MIME entity may 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.
+
+   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 PKCS #7 objects 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
+   when signing.  Description of the procedures from [MIME-SPEC] are
+   repeated here, but the reader should 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 be
+   signed, enveloped, or both signed and enveloped. 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 in order that the message can be
+   forwarded to any environment without modification.
+
+   These steps are descriptive rather than prescriptive. The implementor
+   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 removed, 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.
+
+
+
+
+
+Dusse, et. al.               Informational                     [Page 10]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+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 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 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 at
+   all is required.  S/MIME implementations MUST be able to deal with
+   binary MIME objects. If no Content-Transfer-Encoding header is
+   present, the transfer encoding should be considered 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
+
+
+
+Dusse, et. al.               Informational                     [Page 11]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+   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.
+
+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 clear. 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.
+
+   [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 must 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.
+
+
+
+
+Dusse, et. al.               Informational                     [Page 12]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+       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?
+
+       I agree. 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--
+
+3.2 The application/pkcs7-mime Type
+
+   The application/pkcs7-mime type is used to carry PKCS #7 objects of
+   several types including envelopedData and signedData. The details of
+   constructing these entities is described in subsequent sections. This
+   section describes the general characteristics of the
+   application/pkcs7-mime type.
+
+   This MIME type always carries a single PKCS #7 object. The PKCS #7
+   object must always be BER encoding of the ASN.1 syntax describing the
+   object. The contentInfo field of the carried PKCS #7 object always
+   contains a MIME entity that is prepared as described in section 3.1.
+   The contentInfo field must never be empty.
+
+   Since PKCS #7 objects 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.
+
+
+
+Dusse, et. al.               Informational                     [Page 13]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+   Note that this discussion refers to the transfer encoding of the PKCS
+   #7 object or "outside" MIME entity. It is completely distinct from,
+   and unrelated to, the transfer encoding of the MIME entity secured by
+   the PKCS #7 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:
+
+   MIME Type                      File Extension
+
+   application/pkcs7-mime              .p7m
+   (signedData, envelopedData)
+
+   application/pkcs7-mime              .p7c
+   (degenerate signedData
+   "certs-only" message)
+
+   application/pkcs7-signature         .p7s
+
+   application/pkcs10                  .p10
+
+   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
+
+
+
+Dusse, et. al.               Informational                     [Page 14]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+   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.3 Creating an Enveloped-only Message
+
+   This section describes the format for enveloping a MIME entity
+   without signing it.
+
+     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
+             PKCS #7 object of type envelopedData.
+
+     Step 3. The PKCS #7 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 and SignedData, and multipart/signed. In
+   general, the multipart/signed form is preferred for sending, and
+   receiving agents SHOULD 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
+   should be chosen because it depends on the capabilities of all the
+
+
+
+Dusse, et. al.               Informational                     [Page 15]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+   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.
+
+   Messages signed using the signedData format cannot be viewed by a
+   recipient unless they have S/MIME facilities. However, if they have
+   S/MIME facilities, these messages can always be verified if they were
+   not changed in transit.
+
+3.4.2 Signing Using application/pkcs7-mime and 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
+             PKCS #7 object of type signedData
+
+     Step 3. The PKCS #7 object is inserted into an
+             application/pkcs7-mime MIME entity
+
+   The smime-type parameter for messages using application/pkcs7-mime
+   and 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
+
+
+
+
+
+
+Dusse, et. al.               Informational                     [Page 16]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+3.4.3 Signing Using the multipart/signed Format
+
+   This format is a clear-signing format. Recipients without any S/MIME
+   or PKCS 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 to be signed; the second part contains the
+   signature, which is a PKCS #7 detached signature.
+
+3.4.3.1 The application/pkcs7-signature MIME Type
+
+   This MIME type always contains a single PKCS #7 object of type
+   signedData.  The contentInfo field of the PKCS #7 object must be
+   empty. The signerInfos field contains the signatures for the MIME
+   entity. The details of the registered type are given in Appendix D.
+
+   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 PKCS #7 processing in order
+             to obtain an object of type signedData with an empty
+             contentInfo field.
+
+     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 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.
+
+
+
+
+Dusse, et. al.               Informational                     [Page 17]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+   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 used in the calculation of
+   the Message Integrity Check. The value of the micalg parameter SHOULD
+   be one of the following:
+
+   Algorithm used     Value
+   --------------     ---------
+   MD5                md5
+   SHA-1              sha1
+   any other          unknown
+
+   (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.
+
+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--
+
+3.5 Signing and Encrypting
+
+   To achieve signing and enveloping, any of the signed-only and
+   encrypted-only formats may be nested. This is allowed because the
+   above formats are all MIME entities, and because they all secure MIME
+   entities.
+
+
+
+
+
+Dusse, et. al.               Informational                     [Page 18]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+   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 either sign a message first, or to envelope the
+   message first. It is up to the implementor 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 may be useful in an environment were automatic signature
+   verification is desired, as no private key material is required to
+   verify a signature.
+
+3.6 Creating a Certificates-only Message
+
+   The certificates only message or MIME entity is used to transport
+   certificates, such as in response to a registration request. This
+   format can also be used to convey CRLs.
+
+     Step 1. The certificates are made available to the PKCS #7
+             generating process which creates a PKCS #7 object of type
+             signedData.  The contentInfo and signerInfos fields must be
+             empty.
+
+     Step 2. The PKCS #7 signedData object is enclosed in an
+             application/pkcs7-mime MIME entity
+
+   The smime-type parameter for a certs-only message is "certs-only".
+   The file extension for this type of message is ".p7c".
+
+3.7 Creating a Registration Request
+
+   A typical application which allows a user to generate cryptographic
+   information has to submit that information to a certification
+   authority, who transforms it into a certificate. PKCS #10 describes a
+   syntax for certification requests. The application/pkcs10 body type
+   MUST be used to transfer a PKCS #10 certification request.
+
+   The details of certification requests and the process of obtaining a
+   certificate are beyond the scope of this memo. Instead, only the
+   format of data used in application/pkcs10 is defined.
+
+3.7.1 Format of the application/pkcs10 Body
+
+   PKCS #10 defines the ASN.1 type CertificationRequest for use in
+   submitting a certification request. Therefore, when the MIME content
+   type application/pkcs10 is used, the body MUST be a
+   CertificationRequest, encoded using the Basic Encoding Rules (BER).
+
+
+
+Dusse, et. al.               Informational                     [Page 19]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+   Although BER is specified, instead of the more restrictive DER, a
+   typical application will use DER since the CertificationRequest's
+   CertificationRequestInfo has to be DER-encoded in order to be signed.
+   A robust application SHOULD output DER, but allow BER or DER on
+   input.
+
+   Data produced by BER or DER is 8-bit, but many transports are limited
+   to 7-bit data. Therefore, a suitable 7-bit Content-Transfer-Encoding
+   SHOULD be applied. The base64 Content-Transfer-Encoding SHOULD be
+   used with application/pkcs10, although any 7-bit transfer encoding
+   may work.
+
+3.7.2 Sending and Receiving an application/pkcs10 Body Part
+
+   For sending a certificate-signing request, the application/pkcs10
+   message format MUST be used to convey a PKCS #10 certificate-signing
+   request. Note that for sending certificates and CRLs messages without
+   any signed content, the application/pkcs7-mime message format MUST be
+   used to convey a degenerate PKCS #7 signedData "certs-only" message.
+
+   To send an application/pkcs10 body, the application generates the
+   cryptographic information for the user. The details of the
+   cryptographic information are beyond the scope of this memo.
+
+     Step 1. The cryptographic information is placed within a PKCS #10
+             CertificationRequest.
+
+     Step 2. The CertificationRequest is encoded according to BER or DER
+             (typically, DER).
+
+     Step 3. As a typical step, the DER-encoded CertificationRequest is
+             also base64 encoded so that it is 7-bit data suitable for
+             transfer in SMTP. This then becomes the body of an
+             application/pkcs10 body part.
+
+   The result might look like this:
+
+       Content-Type: application/pkcs10; name=smime.p10
+       Content-Transfer-Encoding: base64
+       Content-Disposition: attachment; filename=smime.p10
+
+       rfvbnj756tbBghyHhHUujhJhjH77n8HHGT9HG4VQpfyF467GhIGfHfYT6
+       7n8HHGghyHhHUujhJh4VQpfyF467GhIGfHfYGTrfvbnjT6jH7756tbB9H
+       f8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4
+       0GhIGfHfQbnj756YT64V
+
+   A typical application only needs to send a certification request. It
+   is a certification authority that has to receive and process the
+
+
+
+Dusse, et. al.               Informational                     [Page 20]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+   request. The steps for recovering the CertificationRequest from the
+   message are straightforward but are not presented here. The
+   procedures for processing the certification request are beyond the
+   scope of this document.
+
+3.8 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 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:   application/pkcs10
+   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, aps, p7c, p10
+
+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 memo does not cover how S/MIME agents handle
+   certificates, only what they do after a certificate has been
+   validated or rejected. S/MIME certification issues are covered in a
+   different document.
+
+   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
+
+
+
+Dusse, et. al.               Informational                     [Page 21]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+   "store and protect" certificates for correspondents in such a way so
+   as to guarantee their later retrieval.
+
+4.1 Key Pair Generation
+
+   An S/MIME agent or some related administrative utility or function
+   MUST be capable of generating RSA key pairs on behalf of the user.
+   Each key pair MUST be generated from a good source of non-
+   deterministic random input and protected in a secure fashion.
+
+   A user agent SHOULD generate RSA key pairs at a minimum key size of
+   768 bits and a maximum key size of 1024 bits. A user agent MUST NOT
+   generate RSA key pairs less than 512 bits long. 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.
+
+   Implementors should be aware that multiple (active) key pairs may be
+   associated with a single individual. For example, one key pair may be
+   used to support confidentiality, while a different key pair may be
+   used for authentication.
+
+5. Security Considerations
+
+   This entire memo discusses security. Security issues not covered in
+   other parts of the memo include:
+
+   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
+   no cryptography. When feasible, sending and receiving agents should
+   inform senders and recipients 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 memo gives a framework for using those estimates in
+   choosing algorithms.
+
+
+
+Dusse, et. al.               Informational                     [Page 22]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+   If a sending agent is sending the same message using different
+   strengths of cryptography, an attacker watching the communications
+   channel can 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dusse, et. al.               Informational                     [Page 23]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+A. Object Identifiers and Syntax
+
+   The syntax for SMIMECapability is:
+
+   SMIMECapability ::= SEQUENCE {
+       capabilityID OBJECT IDENTIFIER,
+       parameters OPTIONAL ANY DEFINED BY capabilityID }
+
+   SMIMECapabilities ::= SEQUENCE OF SMIMECapability
+
+A.1 Content Encryption Algorithms
+
+RC2-CBC OBJECT IDENTIFIER ::=
+ {iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 2}
+
+For the effective-key-bits (key size) greater than 32 and less than
+256, the RC2-CBC algorithm parameters are encoded as:
+
+RC2-CBC parameter ::=  SEQUENCE {
+ rc2ParameterVersion  INTEGER,
+ iv                   OCTET STRING (8)}
+
+For the effective-key-bits of 40, 64, and 128, the
+rc2ParameterVersion values are 160, 120, 58 respectively.
+
+DES-EDE3-CBC OBJECT IDENTIFIER ::=
+ {iso(1) member-body(2) us(840) rsadsi(113549) encryptionAlgorithm(3) 7}
+
+For DES-CBC and DES-EDE3-CBC, the parameter should be encoded as:
+
+CBCParameter :: IV
+
+where IV ::= OCTET STRING -- 8 octets.
+
+A.2 Digest Algorithms
+
+md5 OBJECT IDENTIFIER ::=
+ {iso(1) member-body(2) us(840) rsadsi(113549) digestAlgorithm(2) 5}
+
+sha-1 OBJECT IDENTIFIER ::=
+ {iso(1) identified-organization(3) oiw(14) secsig(3) algorithm(2) 26}
+
+A.3 Asymmetric Encryption Algorithms
+
+rsaEncryption OBJECT IDENTIFIER ::=
+ {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 1}
+
+
+
+
+
+Dusse, et. al.               Informational                     [Page 24]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+rsa OBJECT IDENTIFIER ::=
+     {joint-iso-ccitt(2) ds(5) algorithm(8) encryptionAlgorithm(1) 1}
+
+A.4 Signature Algorithms
+
+md2WithRSAEncryption OBJECT IDENTIFIER ::=
+     {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 2}
+
+md5WithRSAEncryption OBJECT IDENTIFIER ::=
+     {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 4}
+
+sha-1WithRSAEncryption OBJECT IDENTIFIER ::=
+     {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-1(1) 5}
+
+A.5 Signed Attributes
+
+signingTime OBJECT IDENTIFIER ::=
+     {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 5}
+
+smimeCapabilities OBJECT IDENTIFIER ::=
+    {iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 15}
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dusse, et. al.               Informational                     [Page 25]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+B. References
+
+   [3DES] W. Tuchman, "Hellman Presents No Shortcut Solutions To DES,"
+   IEEE Spectrum, v. 16, n. 7, July 1979, pp40-41.
+
+   [CHARSETS] Character sets assigned by IANA. See
+   <ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets>.
+
+   [CONTDISP] Troost, R., Dorner, S and K. Moore, "Communicating
+   Presentation Information in Internet Messages:  The Content-
+   Disposition Header Field", RFC 2183, August 1997.
+
+   [DES] ANSI X3.106, "American National Standard for Information
+   Systems-Data Link Encryption," American National Standards Institute,
+   1983.
+
+   [MD5] Rivest, R., "The MD5 Message Digest Algorithm", RFC 1321, April
+   1992.
+
+   [MIME-SPEC] The primary definition of MIME.
+
+   Freed, N., and N. Borenstein, "MIME Part 1: Format of Internet
+   Message Bodies", RFC 2045, November 1996.
+
+   Freed, N., and N. Borenstein, "MIME Part 2: Media Types", RFC 2046,
+   November 1996.
+
+   Moore, K., "MIME Part 3: Message Header Extensions for Non-ASCII
+   Text", RFC 2047, November 1996.
+
+   Freed, N., Klensin, J., and J. Postel, "MIME Part 4: Registration
+   Procedures", RFC 2048, November 1996.
+
+   Freed, N., and N. Borenstein, "MIME Part 5: 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.
+
+   [PKCS-1] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC
+   2313, March 1998.
+
+   [PKCS-7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version
+   1.5", RFC 2315, March 1998.
+
+
+
+Dusse, et. al.               Informational                     [Page 26]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+   [PKCS-10] Kaliski, B., "PKCS #10: Certification Request Syntax
+   Version 1.5", RFC 2314, March 1998.
+
+   [RC2] Rivest, R., "Description of the RC2(r) Encryption Algorithm",
+   RFC 2268, January 1998.
+
+   [SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard," National
+   Institute of Standards and Technology, U.S. Department of Commerce,
+   DRAFT, 31 May 1994.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dusse, et. al.               Informational                     [Page 27]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+C. Compatibility with Prior Practice in S/MIME
+
+   S/MIME was originally developed by RSA Data Security, Inc. Many
+   developers implemented S/MIME agents before this document was
+   published. All S/MIME receiving agents SHOULD make every attempt to
+   interoperate with these earlier implementations of S/MIME.
+
+C.1 Early MIME Types
+
+   Some early implementations of S/MIME agents used the following MIME
+   types:
+
+   application/x-pkcs7-mime
+   application/x-pkcs7-signature
+   application/x-pkcs10
+
+   In each case, the "x-" subtypes correspond to the subtypes described
+   in this document without the "x-".
+
+C.2 Profiles
+
+   Early S/MIME documentation had two profiles for encryption:
+   "restricted" and "unrestricted". The difference between these
+   profiles historically came about due to US Government export
+   regulations, as described at the end of this section. It is expected
+   that in the future, there will be few agents that only use the
+   restricted profile.
+
+   Briefly, the restricted profile required the ability to encrypt and
+   decrypt using RSA's trade-secret RC2 algorithm in CBC mode with 40-
+   bit keys. The unrestricted profile required the ability to encrypt
+   and decrypt using RSA's trade-secret RC2 algorithm in CBC mode with
+   40-bit keys, and to encrypt and decrypt using tripleDES. The
+   restricted profile also had non-mandatory suggestions for other
+   algorithms, but these were not widely implemented.
+
+   It is important to note that many current implementations of S/MIME
+   use the restricted profile.
+
+C.2.1 Historical Reasons for the Existence of Two Encryption Profiles
+
+   Due to US Government export regulations, an S/MIME agent which
+   supports a strong content encryption algorithm such as DES would not
+   be freely exportable outside of North America. US software
+   manufacturers have been compelled to incorporate an exportable or
+   "restricted" content encryption algorithm in order to create a widely
+   exportable version of their product.  S/MIME agents created in the US
+   and intended for US domestic use (or use under special State
+
+
+
+Dusse, et. al.               Informational                     [Page 28]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+   Department export licenses) can utilize stronger, "unrestricted"
+   content encryption. However, in order to achieve interoperability,
+   such agents need to support whatever exportable algorithm is
+   incorporated in restricted S/MIME agents.
+
+   The RC2 symmetric encryption algorithm has been approved by the US
+   Government for "expedited" export licensing at certain key sizes.
+   Consequently, support for the RC2 algorithm in CBC mode is required
+   for baseline interoperability in all S/MIME implementations. Support
+   for other strong symmetric encryption algorithms such as RC5 CBC, DES
+   CBC and DES EDE3-CBC for content encryption is strongly encouraged
+   where possible.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dusse, et. al.               Informational                     [Page 29]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+D. Request for New MIME Subtypes
+
+D.1 application/pkcs7-mime
+
+   To: ietf-types@iana.org
+   Subject: Registration of MIME media type application/pkcs7-mime
+
+   MIME media type name: application
+
+   MIME subtype name: pkcs7-mime
+
+   Required parameters: none
+
+   Optional parameters: name, filename, smime-type
+
+   Encoding considerations: Will be binary data, therefore should use
+   base64 encoding
+
+   Security considerations: Described in [PKCS-7]
+
+   Interoperability considerations: Designed to carry data formatted
+   with PKCS-7, as described in [PKCS-7]
+
+   Published specification: RFC 2311
+
+   Applications which use this media type: Secure Internet mail and
+   other secure data transports.
+
+   Additional information:
+   File extension(s): .p7m and .p7c
+   Macintosh File Type Code(s):
+
+   Person & email address to contact for further information:
+   Steve Dusse, spock@rsa.com
+
+   Intended usage: COMMON
+
+D.2 application/pkcs7-signature
+
+   To: ietf-types@iana.org
+   Subject: Registration of MIME media type application/pkcs7-signature
+
+   MIME media type name: application
+
+   MIME subtype name: pkcs7-signature
+
+   Required parameters: none
+
+
+
+
+Dusse, et. al.               Informational                     [Page 30]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+   Optional parameters: name, filename
+
+   Encoding considerations: Will be binary data, therefore should use
+   base64 encoding
+
+   Security considerations: Described in [PKCS-7]
+
+   Interoperability considerations: Designed to carry digital
+   signatures with PKCS-7, as described in [PKCS-7]
+
+   Published specification: RFC 2311
+
+   Applications which use this media type: Secure Internet mail and
+   other secure data transports.
+
+   Additional information:
+   File extension(s): .p7s
+   Macintosh File Type Code(s):
+
+   Person & email address to contact for further information:
+   Steve Dusse, spock@rsa.com
+
+   Intended usage: COMMON
+
+D.3 application/pkcs10
+
+   To: ietf-types@iana.org
+   Subject: Registration of MIME media type application/pkcs10
+
+   MIME media type name: application
+
+   MIME subtype name: pkcs10
+
+   Required parameters: none
+
+   Optional parameters: name, filename
+
+   Encoding considerations: Will be binary data, therefore should use
+   base64 encoding
+
+   Security considerations: Described in [PKCS-10]
+
+   Interoperability considerations: Designed to carry digital
+   certificates formatted with PKCS-10, as described in [PKCS-10]
+
+   Published specification: RFC 2311
+
+   Applications which use this media type: Secure Internet mail and
+
+
+
+Dusse, et. al.               Informational                     [Page 31]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+   other transports where certificates are required.
+
+   Additional information:
+   File extension(s): .p10
+   Macintosh File Type Code(s):
+
+   Person & email address to contact for further information:
+   Steve Dusse, spock@rsa.com
+
+   Intended usage: COMMON
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dusse, et. al.               Informational                     [Page 32]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+E. Encapsulating Signed Messages for Internet Transport
+
+   The rationale behind the multiple formats for signing has to do with
+   the MIME subtype defaulting rules of the application and multipart
+   top-level types, and the behavior of currently deployed gateways and
+   mail user agents.
+
+   Ideally, the multipart/signed format would be the only format used
+   because it provides a truly backwards compatible way to sign MIME
+   entities. In a pure MIME environment with very capable user agents,
+   this would be possible. The world, however, is more complex than
+   this.
+
+   One problem with the multipart/signed format occurs with gateways to
+   non-MIME environments. In these environments, the gateway will
+   generally not be S/MIME aware, will not recognize the
+   multipart/signed type, and will default its treatment to
+   multipart/mixed as is prescribed by the MIME standard. The real
+   problem occurs when the gateway also applies conversions to the MIME
+   structure of the original message that is being signed and is
+   contained in the first part of the multipart/signed structure, such
+   as the gateway converting text and attachments to the local format.
+   Because the signature is over the MIME structure of the original
+   message, but the original message is now decomposed and transformed,
+   the signature cannot be verified. Because MIME encoding of a
+   particular set of body parts can be done in many different ways,
+   there is no way to reconstruct the original MIME entity over which
+   the signature was computed.
+
+   A similar problem occurs when an attempt is made to combine an
+   existing user agent with a stand-alone S/MIME facility. Typical user
+   agents do not have the ability to make a multipart sub-entity
+   available to a stand-alone application in the same way they make leaf
+   MIME entities available to "viewer" applications. This user agent
+   behavior is not required by the MIME standard and thus not widely
+   implemented. The result is that it is impossible for most user agents
+   to hand off the entire multipart/signed entity to a stand-alone
+   application.
+
+E.1 Solutions to the Problem
+
+   To work around these two problems, the application/pkcs7-mime type
+   can be used. When going through a gateway, it will be defaulted to
+   the MIME type of application/octet-stream and treated as a single
+   opaque entity. That is, the message will be treated as an attachment
+   of unknown type, converted into the local representation for an
+   attachment and thus can be made available to an S/MIME facility
+   completely intact. A similar result is achieved when a user agent
+
+
+
+Dusse, et. al.               Informational                     [Page 33]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+   similarly treats the application/pkcs7-mime MIME entity as a simple
+   leaf node of the MIME structure and makes it available to viewer
+   applications.
+
+   Another way to work around these problems is to encapsulate the
+   multipart/signed MIME entity in a MIME entity that will not be
+   damaged by the gateway. At the time that this memo is being written,
+   there is a proposal for a MIME entity "application/mime" for this
+   purpose. However, no implementations of S/MIME use this type of
+   wrapping.
+
+E.2 Encapsulation in an Non-MIME Environment
+
+   While this document primarily addresses the Internet, it is useful to
+   compose and receive S/MIME secured messages in non-MIME environments.
+   This is particularly the case when it is desired that security be
+   implemented end-to-end. Other discussion here addresses the receipt
+   of S/MIME messages in non-MIME environments. Here the composition of
+   multipart/signed entities is addressed.
+
+   When a message is to be sent in such an environment, the
+   multipart/signed entity is created as described above. That entity is
+   then treated as an opaque stream of bits and added to the message as
+   an attachment. It must have a file name that ends with ".aps", as
+   this is the sole mechanism for recognizing it as an S/MIME message by
+   the receiving agent.
+
+   When this message arrives in a MIME environment, it is likely to have
+   a MIME type of application/octet-stream, with MIME parameters giving
+   the filename for the attachment. If the intervening gateway has
+   carried the file type, it will end in ".aps" and be recognized as an
+   S/MIME message.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dusse, et. al.               Informational                     [Page 34]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+F. Acknowledgements
+
+   Significant contributions to the content of this memo were made by
+   many people, including Jim Schaad, Jeff Thompson, and Jeff Weinstein.
+
+G. Authors' Addresses
+
+   Steve Dusse
+   RSA Data Security, Inc.
+   100 Marine Parkway, #500
+   Redwood City, CA  94065  USA
+
+   Phone: (415) 595-8782
+   EMail: spock@rsa.com
+
+
+   Paul Hoffman
+   Internet Mail Consortium
+   127 Segre Place
+   Santa Cruz, CA  95060
+
+   Phone: (408) 426-9827
+   EMail: phoffman@imc.org
+
+
+   Blake Ramsdell
+   Worldtalk
+   13122 NE 20th St., Suite C
+   Bellevue, WA 98005
+
+   Phone: (425) 882-8861
+   EMail: blaker@deming.com
+
+
+   Laurence Lundblade
+   QUALCOMM Incorporated
+   Eudora Division
+   6455 Lusk Boulevard
+   San Diego, California 92121-2779
+
+   Phone: (800) 238-3672
+   EMail: lgl@qualcomm.com
+
+
+
+
+
+
+
+
+
+Dusse, et. al.               Informational                     [Page 35]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+   Lisa Repka
+   Netscape Communications Corporation
+   501 East Middlefield Road
+   Mountain View, CA  94043
+
+   Phone: (415) 254-1900
+   EMail: repka@netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dusse, et. al.               Informational                     [Page 36]
+
+RFC 2311         S/MIME Version 2 Message Specification       March 1998
+
+
+H.  Full Copyright Statement
+
+   Copyright (C) The Internet Society (1998).  All Rights Reserved.
+
+   This document and translations of it may be copied and furnished to
+   others, and derivative works that comment on or otherwise explain it
+   or assist in its implementation may be prepared, copied, published
+   and distributed, in whole or in part, without restriction of any
+   kind, provided that the above copyright notice and this paragraph are
+   included on all such copies and derivative works.  However, this
+   document itself may not be modified in any way, such as by removing
+   the copyright notice or references to the Internet Society or other
+   Internet organizations, except as needed for the purpose of
+   developing Internet standards in which case the procedures for
+   copyrights defined in the Internet Standards process must be
+   followed, or as required to translate it into languages other than
+   English.
+
+   The limited permissions granted above are perpetual and will not be
+   revoked by the Internet Society or its successors or assigns.
+
+   This document and the information contained herein is provided on an
+   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+   TASK FORCE DISCLAIMS 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Dusse, et. al.               Informational                     [Page 37]
+