rfc2630.txt

RFC 的详细文档！

      on the content with a signer-specific message-digest algorithm.
      If the signer is signing any information other than the content,
      the message digest of the content and the other information are
      digested with the signer's message digest algorithm (see Section
      5.4), and the result becomes the "message digest."

      2.  For each signer, the message digest is digitally signed using
      the signer's private key.

      3.  For each signer, the signature value and other signer-specific
      information are collected into a SignerInfo value, as defined in
      Section 5.3.  Certificates and CRLs for each signer, and those not
      corresponding to any signer, are collected in this step.

      4.  The message digest algorithms for all the signers and the
      SignerInfo values for all the signers are collected together with
      the content into a SignedData value, as defined in Section 5.1.

   A recipient independently computes the message digest.  This message
   digest and the signer's public key are used to verify the signature
   value.  The signer's public key is referenced either by an issuer
   distinguished name along with an issuer-specific serial number or by
   a subject key identifier that uniquely identifies the certificate
   containing the public key.  The signer's certificate may be included
   in the SignedData certificates field.




Housley                     Standards Track                     [Page 6]

RFC 2630              Cryptographic Message Syntax             June 1999


   This section is divided into six parts.  The first part describes the
   top-level type SignedData, the second part describes
   EncapsulatedContentInfo, the third part describes the per-signer
   information type SignerInfo, and the fourth, fifth, and sixth parts
   describe the message digest calculation, signature generation, and
   signature verification processes, respectively.

5.1  SignedData Type

   The following object identifier identifies the signed-data content
   type:

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

   The signed-data content type shall have ASN.1 type SignedData:

      SignedData ::= SEQUENCE {
        version CMSVersion,
        digestAlgorithms DigestAlgorithmIdentifiers,
        encapContentInfo EncapsulatedContentInfo,
        certificates [0] IMPLICIT CertificateSet OPTIONAL,
        crls [1] IMPLICIT CertificateRevocationLists OPTIONAL,
        signerInfos SignerInfos }

      DigestAlgorithmIdentifiers ::= SET OF DigestAlgorithmIdentifier

      SignerInfos ::= SET OF SignerInfo

   The fields of type SignedData have the following meanings:

      version is the syntax version number.  If no attribute
      certificates are present in the certificates field, the
      encapsulated content type is id-data, and all of the elements of
      SignerInfos are version 1, then the value of version shall be 1.
      Alternatively, if attribute certificates are present, the
      encapsulated content type is other than id-data, or any of the
      elements of SignerInfos are version 3, then the value of version
      shall be 3.

      digestAlgorithms is a collection of message digest algorithm
      identifiers.  There may be any number of elements in the
      collection, including zero.  Each element identifies the message
      digest algorithm, along with any associated parameters, used by
      one or more signer.  The collection is intended to list the
      message digest algorithms employed by all of the signers, in any
      order, to facilitate one-pass signature verification.  The message
      digesting process is described in Section 5.4.



Housley                     Standards Track                     [Page 7]

RFC 2630              Cryptographic Message Syntax             June 1999


      encapContentInfo is the signed content, consisting of a content
      type identifier and the content itself.  Details of the
      EncapsulatedContentInfo type are discussed in section 5.2.

      certificates is a collection of certificates.  It is intended that
      the set of certificates be sufficient to contain chains from a
      recognized "root" or "top-level certification authority" to all of
      the signers in the signerInfos field.  There may be more
      certificates than necessary, and there may be certificates
      sufficient to contain chains from two or more independent top-
      level certification authorities.  There may also be fewer
      certificates than necessary, if it is expected that recipients
      have an alternate means of obtaining necessary certificates (e.g.,
      from a previous set of certificates).  As discussed above, if
      attribute certificates are present, then the value of version
      shall be 3.

      crls is a collection of certificate revocation lists (CRLs).  It
      is intended that the set contain information sufficient to
      determine whether or not the certificates in the certificates
      field are valid, but such correspondence is not necessary.  There
      may be more CRLs than necessary, and there may also be fewer CRLs
      than necessary.

      signerInfos is a collection of per-signer information.  There may
      be any number of elements in the collection, including zero.  The
      details of the SignerInfo type are discussed in section 5.3.

5.2  EncapsulatedContentInfo Type

   The content is represented in the type EncapsulatedContentInfo:

      EncapsulatedContentInfo ::= SEQUENCE {
        eContentType ContentType,
        eContent [0] EXPLICIT OCTET STRING OPTIONAL }

      ContentType ::= OBJECT IDENTIFIER

   The fields of type EncapsulatedContentInfo have the following
   meanings:

      eContentType is an object identifier that uniquely specifies the
      content type.

      eContent is the content itself, carried as an octet string.  The
      eContent need not be DER encoded.





Housley                     Standards Track                     [Page 8]

RFC 2630              Cryptographic Message Syntax             June 1999


   The optional omission of the eContent within the
   EncapsulatedContentInfo field makes it possible to construct
   "external signatures."  In the case of external signatures, the
   content being signed is absent from the EncapsulatedContentInfo value
   included in the signed-data content type.  If the eContent value
   within EncapsulatedContentInfo is absent, then the signatureValue is
   calculated and the eContentType is assigned as though the eContent
   value was present.

   In the degenerate case where there are no signers, the
   EncapsulatedContentInfo value being "signed" is irrelevant.  In this
   case, the content type within the EncapsulatedContentInfo value being
   "signed" should be id-data (as defined in section 4), and the content
   field of the EncapsulatedContentInfo value should be omitted.

5.3  SignerInfo Type

   Per-signer information is represented in the type SignerInfo:

      SignerInfo ::= SEQUENCE {
        version CMSVersion,
        sid SignerIdentifier,
        digestAlgorithm DigestAlgorithmIdentifier,
        signedAttrs [0] IMPLICIT SignedAttributes OPTIONAL,
        signatureAlgorithm SignatureAlgorithmIdentifier,
        signature SignatureValue,
        unsignedAttrs [1] IMPLICIT UnsignedAttributes OPTIONAL }

      SignerIdentifier ::= CHOICE {
        issuerAndSerialNumber IssuerAndSerialNumber,
        subjectKeyIdentifier [0] SubjectKeyIdentifier }

      SignedAttributes ::= SET SIZE (1..MAX) OF Attribute

      UnsignedAttributes ::= SET SIZE (1..MAX) OF Attribute

      Attribute ::= SEQUENCE {
        attrType OBJECT IDENTIFIER,
        attrValues SET OF AttributeValue }

      AttributeValue ::= ANY

      SignatureValue ::= OCTET STRING

   The fields of type SignerInfo have the following meanings:

      version is the syntax version number.  If the SignerIdentifier is
      the CHOICE issuerAndSerialNumber, then the version shall be 1.  If



Housley                     Standards Track                     [Page 9]

RFC 2630              Cryptographic Message Syntax             June 1999


      the SignerIdentifier is subjectKeyIdentifier, then the version
      shall be 3.

      sid specifies the signer's certificate (and thereby the signer's
      public key).  The signer's public key is needed by the recipient
      to verify the signature.  SignerIdentifier provides two
      alternatives for specifying the signer's public key.  The
      issuerAndSerialNumber alternative identifies the signer's
      certificate by the issuer's distinguished name and the certificate
      serial number; the subjectKeyIdentifier identifies the signer's
      certificate by the X.509 subjectKeyIdentifier extension value.

      digestAlgorithm identifies the message digest algorithm, and any
      associated parameters, used by the signer.  The message digest is
      computed on either the content being signed or the content
      together with the signed attributes using the process described in
      section 5.4.  The message digest algorithm should be among those
      listed in the digestAlgorithms field of the associated SignerData.

      signedAttributes is a collection of attributes that are signed.
      The field is optional, but it must be present if the content type
      of the EncapsulatedContentInfo value being signed is not id-data.
      Each SignedAttribute in the SET must be DER encoded.  Useful
      attribute types, such as signing time, are defined in Section 11.
      If the field is present, it must contain, at a minimum, the
      following two attributes:

         A content-type attribute having as its value the content type
         of the EncapsulatedContentInfo value being signed.  Section
         11.1 defines the content-type attribute.  The content-type
         attribute is not required when used as part of a
         countersignature unsigned attribute as defined in section 11.4.

         A message-digest attribute, having as its value the message
         digest of the content.  Section 11.2 defines the message-digest
         attribute.

      signatureAlgorithm identifies the signature algorithm, and any
      associated parameters, used by the signer to generate the digital
      signature.

      signature is the result of digital signature generation, using the
      message digest and the signer's private key.

      unsignedAttributes is a collection of attributes that are not
      signed.  The field is optional.  Useful attribute types, such as
      countersignatures, are defined in Section 11.




Housley                     Standards Track                    [Page 10]

RFC 2630              Cryptographic Message Syntax             June 1999


   The fields of type SignedAttribute and UnsignedAttribute have the
   following meanings:

      attrType indicates the type of attribute.  It is an object
      identifier.

      attrValues is a set of values that comprise the attribute.  The
      type of each value in the set can be determined uniquely by
      attrType.

5.4  Message Digest Calculation Process

   The message digest calculation process computes a message digest on
   either the content being signed or the content together with the
   signed attributes.  In either case, the initial input to the message
   digest calculation process is the "value" of the encapsulated content
   being signed.  Specifically, the initial input is the
   encapContentInfo eContent OCTET STRING to which the signing process
   is applied.  Only the octets comprising the value of the eContent
   OCTET STRING are input to the message digest algorithm, not the tag
   or the length octets.

   The result of the message digest calculation process depends on
   whether the signedAttributes field is present.  When the field is
   absent, the result is just the message digest of the content as
   described above.  When the field is present, however, the result is
   the message digest of the complete DER encoding of the
   SignedAttributes value contained in the signedAttributes field.
   Since the SignedAttributes value, when present, must contain the
   content type and the content message digest attributes, those values
   are indirectly included in the result.  The content type attribute is
   not required when used as part of a countersignature unsigned
   attribute as defined in section 11.4.  A separate encoding of the
   signedAttributes field is performed for message digest calculation.
   The IMPLICIT [0] tag in the signedAttributes field is not used for
   the DER encoding, rather an EXPLICIT SET OF tag is used.  That is,
   the DER encoding of the SET OF tag, rather than of the IMPLICIT [0]
   tag, is to be included in the message digest calculation along with
   the length and content octets of the SignedAttributes value.

   When the signedAttributes field is absent, then only the octets
   comprising the value of the signedData encapContentInfo eContent
   OCTET STRING (e.g., the contents of a file) are input to the message
   digest calculation.  This has the advantage that the length of the
   content being signed need not be known in advance of the signature
   generation process.