rfc3369.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,524 行 · 第 1/5 页

Network Working Group                                         R. Housley
Request for Comments: 3369                              RSA Laboratories
Obsoletes: 2630, 3211                                        August 2002
Category: Standards Track


                   Cryptographic Message Syntax (CMS)

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 (2002).  All Rights Reserved.

Abstract

   This document describes the Cryptographic Message Syntax (CMS).  This
   syntax is used to digitally sign, digest, authenticate, or encrypt
   arbitrary message content.

Table of Contents

   1.   Introduction ................................................  3
   1.1  Changes Since RFC 2630 ......................................  3
   1.2  Terminology .................................................  4
   2.   General Overview ............................................  4
   3.   General Syntax ..............................................  5
   4.   Data Content Type ...........................................  5
   5.   Signed-data Content Type ....................................  6
   5.1  SignedData Type .............................................  7
   5.2  EncapsulatedContentInfo Type ................................  9
   5.2.1  Compatibility with PKCS #7 ................................  9
   5.3  SignerInfo Type ............................................. 11
   5.4  Message Digest Calculation Process .......................... 13
   5.5  Signature Generation Process ................................ 14
   5.6  Signature Verification Process .............................. 14
   6.   Enveloped-data Content Type ................................. 14
   6.1  EnvelopedData Type .......................................... 16
   6.2  RecipientInfo Type .......................................... 18
   6.2.1  KeyTransRecipientInfo Type ................................ 19
   6.2.2  KeyAgreeRecipientInfo Type ................................ 20
   6.2.3  KEKRecipientInfo Type ..................................... 22



Housley                     Standards Track                     [Page 1]

RFC 3369              Cryptographic Message Syntax           August 2002


   6.2.4  PasswordRecipientInfo Type ................................ 23
   6.2.5  OtherRecipientInfo Type ................................... 24
   6.3  Content-encryption Process .................................. 24
   6.4  Key-encryption Process ...................................... 25
   7.   Digested-data Content Type .................................. 25
   8.   Encrypted-data Content Type ................................. 26
   9.   Authenticated-data Content Type ............................. 27
   9.1  AuthenticatedData Type ...................................... 28
   9.2  MAC Generation .............................................. 29
   9.3  MAC Verification ............................................ 31
   10.  Useful Types ................................................ 31
   10.1  Algorithm Identifier Types ................................. 31
   10.1.1  DigestAlgorithmIdentifier ................................ 31
   10.1.2  SignatureAlgorithmIdentifier ............................. 32
   10.1.3  KeyEncryptionAlgorithmIdentifier ......................... 32
   10.1.4  ContentEncryptionAlgorithmIdentifier ..................... 32
   10.1.5  MessageAuthenticationCodeAlgorithm ....................... 32
   10.1.6  KeyDerivationAlgorithmIdentifier ......................... 33
   10.2  Other Useful Types ......................................... 33
   10.2.1  CertificateRevocationLists ............................... 33
   10.2.2  CertificateChoices ....................................... 33
   10.2.3  CertificateSet ........................................... 34
   10.2.4  IssuerAndSerialNumber .................................... 34
   10.2.5  CMSVersion ............................................... 35
   10.2.6  UserKeyingMaterial ....................................... 35
   10.2.7  OtherKeyAttribute ........................................ 35
   11.  Useful Attributes ........................................... 35
   11.1  Content Type ............................................... 36
   11.2  Message Digest ............................................. 36
   11.3  Signing Time ............................................... 37
   11.4  Countersignature ........................................... 39
   12.  ASN.1 Modules ............................................... 40
   12.1  CMS ASN.1 Module ........................................... 40
   12.2  Version 1 Attribute Certificate ASN.1 Module ............... 46
   13.  References .................................................. 47
   14.  Security Considerations ..................................... 48
   15.  Acknowledgments ............................................. 50
   16.  Author Address .............................................. 50
   17.  Full Copyright Statement .................................... 51












Housley                     Standards Track                     [Page 2]

RFC 3369              Cryptographic Message Syntax           August 2002


1. Introduction

   This document describes the Cryptographic Message Syntax (CMS).  This
   syntax is used to digitally sign, digest, authenticate, or encrypt
   arbitrary message content.

   The CMS describes an encapsulation syntax for data protection.  It
   supports digital signatures and encryption.  The syntax allows
   multiple encapsulations; one encapsulation envelope can be nested
   inside another.  Likewise, one party can digitally sign some
   previously encapsulated data.  It also allows arbitrary attributes,
   such as signing time, to be signed along with the message content,
   and provides for other attributes such as countersignatures to be
   associated with a signature.

   The CMS can support a variety of architectures for certificate-based
   key management, such as the one defined by the PKIX working group
   [PROFILE].

   The CMS values are generated using ASN.1 [X.208-88], using BER-
   encoding [X.209-88].  Values are typically represented as octet
   strings.  While many systems are capable of transmitting arbitrary
   octet strings reliably, it is well known that many electronic mail
   systems are not.  This document does not address mechanisms for
   encoding octet strings for reliable transmission in such
   environments.

   The CMS is derived from PKCS #7 version 1.5 as specified in RFC 2315
   [PKCS#7].  Wherever possible, backward compatibility is preserved;
   however, changes were necessary to accommodate version 1 attribute
   certificate transfer, key agreement and symmetric key-encryption key
   techniques for key management.

1.1  Changes Since RFC 2630

   This document obsoletes RFC 2630 [OLDCMS] and RFC 3211 [PWRI].
   Password-based key management is included in the CMS specification,
   and an extension mechanism to support new key management schemes
   without further changes to the CMS is specified.  Backward
   compatibility with RFC 2630 and RFC 3211 is preserved; however,
   version 2 attribute certificate transfer is added.  The use of
   version 1 attribute certificates is deprecated.

   S/MIME v2 signatures [OLDMSG], which are based on PKCS#7 version 1.5,
   are compatible with S/MIME v3 signatures [MSG], which are based on
   RFC 2630.  However, there are some subtle compatibility issues with
   signatures using PKCS#7 version 1.5 and the CMS.  These issues are
   discussed in section 5.2.1.



Housley                     Standards Track                     [Page 3]

RFC 3369              Cryptographic Message Syntax           August 2002


   Specific cryptographic algorithms are not discussed in this document,
   but they were discussed in RFC 2630.  The discussion of specific
   cryptographic algorithms has been moved to a separate document
   [CMSALG].  Separation of the protocol and algorithm specifications
   allows the IETF to update each document independently.  This
   specification does not require the implementation of any particular
   algorithms.  Rather, protocols that rely on the CMS are expected to
   choose appropriate algorithms for their environment.  The algorithms
   may be selected from [CMSALG] or elsewhere.

1.2  Terminology

   In this document, the key words MUST, MUST NOT, REQUIRED, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as
   described in [STDWORDS].

2  General Overview

   The CMS is general enough to support many different content types.
   This document defines one protection content, ContentInfo.
   ContentInfo encapsulates a single identified content type, and the
   identified type may provide further encapsulation.  This document
   defines six content types: data, signed-data, enveloped-data,
   digested-data, encrypted-data, and authenticated-data.  Additional
   content types can be defined outside this document.

   An implementation that conforms to this specification MUST implement
   the protection content, ContentInfo, and MUST implement the data,
   signed-data, and enveloped-data content types.  The other content
   types MAY be implemented.

   As a general design philosophy, each content type permits single pass
   processing using indefinite-length Basic Encoding Rules (BER)
   encoding.  Single-pass operation is especially helpful if content is
   large, stored on tapes, or is "piped" from another process.  Single-
   pass operation has one significant drawback: it is difficult to
   perform encode operations using the Distinguished Encoding Rules
   (DER) [X.509-88] encoding in a single pass since the lengths of the
   various components may not be known in advance.  However, signed
   attributes within the signed-data content type and authenticated
   attributes within the authenticated-data content type need to be
   transmitted in DER form to ensure that recipients can verify a
   content that contains one or more unrecognized attributes.  Signed
   attributes and authenticated attributes are the only data types used
   in the CMS that require DER encoding.






Housley                     Standards Track                     [Page 4]

RFC 3369              Cryptographic Message Syntax           August 2002


3  General Syntax

   The following object identifier identifies the content information
   type:

      id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) rsadsi(113549) pkcs(1) pkcs9(9) smime(16) ct(1) 6 }

   The CMS associates a content type identifier with a content.  The
   syntax MUST have ASN.1 type ContentInfo:

      ContentInfo ::= SEQUENCE {
        contentType ContentType,
        content [0] EXPLICIT ANY DEFINED BY contentType }

      ContentType ::= OBJECT IDENTIFIER

   The fields of ContentInfo have the following meanings:

      contentType indicates the type of the associated content.  It is
      an object identifier; it is a unique string of integers assigned
      by an authority that defines the content type.

      content is the associated content.  The type of content can be
      determined uniquely by contentType.  Content types for data,
      signed-data, enveloped-data, digested-data, encrypted-data, and
      authenticated-data are defined in this document.  If additional
      content types are defined in other documents, the ASN.1 type
      defined SHOULD NOT be a CHOICE type.

4  Data Content Type

   The following object identifier identifies the data content type:

      id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2)
         us(840) rsadsi(113549) pkcs(1) pkcs7(7) 1 }

   The data content type is intended to refer to arbitrary octet
   strings, such as ASCII text files; the interpretation is left to the
   application.  Such strings need not have any internal structure
   (although they could have their own ASN.1 definition or other
   structure).

   S/MIME uses id-data to identify MIME encoded content.  The use of
   this content identifier is specified in RFC 2311 for S/MIME v2
   [OLDMSG] and RFC 2633 for S/MIME v3 [MSG].





Housley                     Standards Track                     [Page 5]

RFC 3369              Cryptographic Message Syntax           August 2002


   The data content type is generally encapsulated in the signed-data,
   enveloped-data, digested-data, encrypted-data, or authenticated-data
   content type.

5.  Signed-data Content Type

   The signed-data content type consists of a content of any type and
   zero or more signature values.  Any number of signers in parallel can
   sign any type of content.

   The typical application of the signed-data content type represents
   one signer's digital signature on content of the data content type.
   Another typical application disseminates certificates and certificate
   revocation lists (CRLs).

   The process by which signed-data is constructed involves the
   following steps:

      1.  For each signer, a message digest, or hash value, is computed