rfc2633.txt

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

Network Working Group                               B. Ramsdell, Editor
Request for Comments: 2633                                    Worldtalk
Category: Standards Track                                     June 1999


                 S/MIME Version 3 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 (1999).  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.

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.



Ramsdell                    Standards Track                     [Page 1]

RFC 2633         S/MIME Version 3 Message Specification        June 1999


   This memo 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 memo also defines the application/pkcs7-
   mime MIME type that can be used to transport those body parts.

   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.

   In order to create S/MIME messages, an S/MIME agent has to follow
   specifications in this memo, as well as the specifications listed in
   the Cryptographic Message Syntax [CMS].

   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
   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].

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.




Ramsdell                    Standards Track                     [Page 2]

RFC 2633         S/MIME Version 3 Message Specification        June 1999


   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.

   Receiving agent: software that interprets and processes S/MIME CMS
   objects, MIME body parts that contain CMS objects, or both.

   Sending agent: software that creates S/MIME CMS objects, MIME body
   parts that contain CMS objects, or both.

   S/MIME agent: user software that is a receiving agent, a sending
   agent, or both.

1.4 Compatibility with Prior Practice of S/MIME

   S/MIME version 3 agents should attempt to have the greatest
   interoperability possible with S/MIME version 2 agents. S/MIME
   version 2 is described in RFC 2311 through RFC 2315, inclusive. RFC
   2311 also has historical information about the development of S/MIME.

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. [CMS] provides additional details
   regarding the use of the cryptographic algorithms.

2.1 DigestAlgorithmIdentifier

   Sending and receiving agents MUST support SHA-1 [SHA1].  Receiving
   agents SHOULD support MD5 [MD5] for the purpose of providing backward
   compatibility with MD5-digested S/MIME v2 SignedData objects.




Ramsdell                    Standards Track                     [Page 3]

RFC 2633         S/MIME Version 3 Message Specification        June 1999


2.2 SignatureAlgorithmIdentifier

   Sending and receiving agents MUST support id-dsa defined in [DSS].
   The algorithm parameters MUST be absent (not encoded as NULL).

   Receiving agents SHOULD support rsaEncryption, defined in [PKCS-1].

   Sending agents SHOULD support rsaEncryption. Outgoing messages are
   signed with a user's private key. The size of the private key is
   determined during key generation.

   Note that S/MIME v2 clients are only capable of verifying digital
   signatures using the rsaEncryption algorithm.

2.3 KeyEncryptionAlgorithmIdentifier

   Sending and receiving agents MUST support Diffie-Hellman defined in
   [DH].

   Receiving agents SHOULD 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 SHOULD support rsaEncryption.

   Note that S/MIME v2 clients are only capable of decrypting content
   encryption keys using the rsaEncryption algorithm.

2.4 General Syntax

   CMS defines multiple content types.  Of these, only the Data,
   SignedData, and EnvelopedData 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
   indicate the message content which has had security services applied
   to it. 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 section 3.4.3 of this document).  As another example,
   when applying encryption to MIME data, the CMS EnvelopedData





Ramsdell                    Standards Track                     [Page 4]

RFC 2633         S/MIME Version 3 Message Specification        June 1999


   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.

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 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)

   Further, receiving agents SHOULD be able to handle zero or one
   instance in the signed attributes of the signingCertificate attribute
   (section 5 in [ESS]).

   Sending agents SHOULD generate one instance of the signingCertificate
   signed attribute in each S/MIME message.

   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.

   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.






Ramsdell                    Standards Track                     [Page 5]

RFC 2633         S/MIME Version 3 Message Specification        June 1999


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. 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"). It also includes a non-algorithm capability which
   is the preference for signedData. 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
   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 SMIMECapabilites 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
   attribute, 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.)






Ramsdell                    Standards Track                     [Page 6]