rfc2311.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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