rfc2315.txt

RFC 的详细文档！

Network Working Group                                          B. Kaliski
Request for Comments: 2315                         RSA Laboratories, East
Category: Informational                                        March 1998


                 PKCS #7: Cryptographic Message Syntax
                              Version 1.5

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.

Overview

   This document describes a general syntax for data that may have
   cryptography applied to it, such as digital signatures and digital
   envelopes. The syntax admits recursion, so that, for example, one
   envelope can be nested inside another, or one party can sign some
   previously enveloped digital data.  It also allows arbitrary
   attributes, such as signing time, to be authenticated along with the
   content of a message, and provides for other attributes such as
   countersignatures to be associated with a signature. A degenerate
   case of the syntax provides a means for disseminating certificates
   and certificate-revocation lists.

1. Scope

   This document is compatible with Privacy-Enhanced Mail (PEM) in that
   signed-data and signed-and-enveloped-data content, constructed in a
   PEM-compatible mode, can be converted into PEM messages without any
   cryptographic operations. PEM messages can similarly be converted
   into the signed-data and signed-and-enveloped data content types.

   This document can support a variety of architectures for
   certificate-based key management, such as the one proposed for
   Privacy-Enhanced Mail in RFC 1422. Architectural decisions such as
   what certificate issuers are considered "top-level," what entities
   certificate issuers are authorized to certify, what distinguished
   names are considered acceptable, and what policies certificate
   issuers must follow (such as signing only with secure hardware, or
   requiring entities to present specific forms of identification) are
   left outside the document.



Kaliski                      Informational                      [Page 1]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


   The values produced according to this document are intended to be
   BER-encoded, which means that the values would typically be
   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 as (say) strings of ASCII
   characters or other techniques for enabling reliable transmission by
   re-encoding the octet string. RFC 1421 suggests one possible solution
   to this problem.

2. References

      FIPS PUB 46-1  National Bureau of Standards. FIPS PUB 46-1:
                Data Encryption Standard. January 1988.

      PKCS #1   RSA Laboratories. PKCS #1: RSA Encryption.
                Version 1.5, November 1993.

      PKCS #6   RSA Laboratories. PKCS #6: Extended-Certificate
                Syntax. Version 1.5, November 1993.

      PKCS #9   RSA Laboratories. PKCS #9: Selected Attribute
                Types. Version 1.1, November 1993.

      RFC 1421  Linn, J., "Privacy Enhancement for
                Internet Electronic Mail: Part I: Message
                Encryption and Authentication Procedures," RFC 1421
                February 1993.

      RFC 1422  Kent, S., "Privacy Enhancement for
                Internet Electronic Mail: Part II: Certificate-
                Based Key Management," RFC 1422, February 1993.

      RFC 1423  Balenson, D., "Privacy Enhancement for
                Internet Electronic Mail: Part III: Algorithms,
                Modes, and Identifiers," RFC 1423, February 1993.

      RFC 1424  Kaliski, B., "Privacy Enhancement for
                Internet Electronic Mail: Part IV: Key
                Certification and Related Services," RFC 1424,
                February 1993.










Kaliski                      Informational                      [Page 2]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


      RFC 1319  Kaliski, B., "The MD2 Message-Digest
                Algorithm," RFC 1319, April 1992.

      RFC 1321  Rivest, R., "The MD5 Message-Digest
                Algorithm," RFC 1321, April 1992.

      X.208     CCITT. Recommendation X.208: Specification of
                Abstract Syntax Notation One (ASN.1). 1988.

      X.209     CCITT. Recommendation X.209: Specification of
                Basic Encoding Rules for Abstract Syntax Notation
                One (ASN.1). 1988.

      X.500     CCITT. Recommendation X.500: The Directory--
                Overview of Concepts, Models and
                Services. 1988.

      X.501     CCITT. Recommendation X.501: The Directory--
                Models. 1988.

      X.509     CCITT. Recommendation X.509: The Directory--
                Authentication Framework. 1988.

      [NIST91]  NIST. Special Publication 500-202: Stable
                Implementation Agreements for Open Systems
                Interconnection Protocols. Version 5, Edition 1,
                Part 12. December 1991.

      [RSA78]   R.L. Rivest, A. Shamir, and L. Adleman. A method
                for obtaining digital signatures and public-key
                cryptosystems. Communications of the ACM,
                21(2):120-126, February 1978.

3. Definitions

   For the purposes of this document, the following definitions apply.

   AlgorithmIdentifier: A type that identifies an algorithm (by object
   identifier) and associated parameters. This type is defined in X.509.

   ASN.1: Abstract Syntax Notation One, as defined in X.208.

   Attribute: A type that contains an attribute type (specified by
   object identifier) and one or more attribute values. This type is
   defined in X.501.

   BER: Basic Encoding Rules, as defined in X.209.




Kaliski                      Informational                      [Page 3]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


   Certificate: A type that binds an entity's distinguished name to a
   public key with a digital signature. This type is defined in X.509.
   This type also contains the distinguished name of the certificate
   issuer (the signer), an issuer-specific serial number, the issuer's
   signature algorithm identifier, and a validity period.

   CertificateSerialNumber: A type that uniquely identifies a
   certificate (and thereby an entity and a public key) among those
   signed by a particular certificate issuer. This type is defined in
   X.509.

   CertificateRevocationList: A type that contains information about
   certificates whose validity an issuer has prematurely revoked. The
   information consists of an issuer name, the time of issue, the next
   scheduled time of issue, and a list of certificate serial numbers and
   their associated revocation times. The CRL is signed by the issuer.
   The type intended by this document is the one defined RFC 1422.

   DER: Distinguished Encoding Rules for ASN.1, as defined in X.509,
   Section 8.7.

   DES: Data Encryption Standard, as defined in FIPS PUB 46-1.

   desCBC: The object identifier for DES in cipher-block chaining (CBC)
   mode, as defined in [NIST91].

   ExtendedCertificate: A type that consists of an X.509 public-key
   certificate and a set of attributes, collectively signed by the
   issuer of the X.509 public-key certificate. This type is defined in
   PKCS #6.

   MD2: RSA Data Security, Inc.'s MD2 message-digest algorithm, as
   defined in RFC 1319.

   md2: The object identifier for MD2, as defined in RFC 1319.

   MD5: RSA Data Security, Inc.'s MD5 message-digest algorithm, as
   defined in RFC 1321.

   md5: The object identifier for MD5, as defined in RFC 1321.

   Name: A type that uniquely identifies or "distinguishes" objects in
   an X.500 directory. This type is defined in X.501. In an X.509
   certificate, the type identifies the certificate issuer and the
   entity whose public key is certified.

   PEM: Internet Privacy-Enhanced Mail, as defined in RFCs 1421-1424.




Kaliski                      Informational                      [Page 4]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


   RSA: The RSA public-key cryptosystem, as defined in [RSA78].

   rsaEncryption: The object identifier for RSA encryption, as defined
   in PKCS #1.

4. Symbols and abbreviations

   No symbols or abbreviations are defined in this document.

5. General overview

   The following nine sections specify useful types, general syntax, six
   content types, and object identifiers.

   The syntax is general enough to support many different content types.
   This document defines six: data, signed data, enveloped data,
   signed-and-enveloped data, digested data, and encrypted data. Other
   content types may be added in the future. The use of content types
   defined outside this document is possible, but is subject to
   bilateral agreement between parties exchanging content.

   This document exports one type, ContentInfo, as well as the various
   object identifiers.

   There are two classes of content types: base and enhanced.  Content
   types in the base class contain "just data," with no cryptographic
   enhancements. Presently, one content type is in this class, the data
   content type. Content types in the enhanced class contain content of
   some type (possibly encrypted), and other cryptographic enhancements.
   For example, enveloped-data content can contain (encrypted) signed-
   data content, which can contain data content. The four non-data
   content types fall into the enhanced class.  The content types in the
   enhanced class thus employ encapsulation, giving rise to the terms
   "outer" content (the one containing the enhancements) and "inner"
   content (the one being enhanced).

   The document is designed such that the enhanced content types can be
   prepared in a single pass using indefinite-length BER encoding, and
   processed in a single pass in any BER encoding. Single-pass operation
   is especially helpful if content is stored on tapes, or is "piped"
   from another process. One of the drawbacks of single-pass operation,
   however, is that it is difficult to output a DER encoding in a single
   pass, since the lengths of the various components may not be known in
   advance. Since DER encoding is required by the signed-data, signed-
   and-enveloped data, and digested-data content types, an extra pass
   may be necessary when a content type other than data is the inner
   content of one of those content types.




Kaliski                      Informational                      [Page 5]

RFC 2315          PKCS #7: Crytographic Message Syntax        March 1998


6. Useful types

   This section defines types that are useful in at least two places in
   the document.

6.1 CertificateRevocationLists

   The CertificateRevocationLists type gives a set of certificate-
   revocation lists. It is intended that the set contain information
   sufficient to determine whether the certificates with which the set
   is associated are "hot listed," but there may be more certificate-
   revocation lists than necessary, or there may be fewer than
   necessary.

   CertificateRevocationLists ::=
     SET OF CertificateRevocationList

6.2 ContentEncryptionAlgorithmIdentifier

   The ContentEncryptionAlgorithmIdentifier type identifies a content-
   encryption algorithm such as DES. A content-encryption algorithm
   supports encryption and decryption operations. The encryption
   operation maps an octet string (the message) to another octet string
   (the ciphertext) under control of a content-encryption key. The
   decryption operation is the inverse of the encryption operation.
   Context determines which operation is intended.

   ContentEncryptionAlgorithmIdentifier ::=
     AlgorithmIdentifier

6.3 DigestAlgorithmIdentifier