rfc3075.txt

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

   The Manifest element is provided to meet additional requirements not
   directly addressed by the mandatory parts of this specification.  Two
   requirements and the way the Manifest satisfies them follows.

   First, applications frequently need to efficiently sign multiple data
   objects even where the signature operation itself is an expensive
   public key signature.  This requirement can be met by including
   multiple Reference elements within SignedInfo since the inclusion of
   each digest secures the data digested.  However, some applications
   may not want the core validation behavior associated with this



Eastlake, et al.            Standards Track                    [Page 11]

RFC 3075          XML-Signature Syntax and Processing         March 2001


   approach because it requires every Reference within SignedInfo to
   undergo reference validation -- the DigestValue elements are checked.
   These applications may wish to reserve reference validation decision
   logic to themselves.  For example, an application might receive a
   signature valid SignedInfo element that includes three Reference
   elements.  If a single Reference fails (the identified data object
   when digested does not yield the specified DigestValue) the signature
   would fail core validation.  However, the application may wish to
   treat the signature over the two valid Reference elements as valid or
   take different actions depending on which fails.  To accomplish this,
   SignedInfo would reference a Manifest element that contains one or
   more Reference elements (with the same structure as those in
   SignedInfo).  Then, reference validation of the Manifest is under
   application control.

   Second, consider an application where many signatures (using
   different keys) are applied to a large number of documents.  An
   inefficient solution is to have a separate signature (per key)
   repeatedly applied to a large SignedInfo element (with many
   References); this is wasteful and redundant.  A more efficient
   solution is to include many references in a single Manifest that is
   then referenced from multiple Signature elements.

   The example below includes a Reference that signs a Manifest found
   within the Object element.

[   ] ...
[m01]   <Reference URI="#MyFirstManifest"
[m02]     Type="http://www.w3.org/2000/09/xmldsig#Manifest">
[m03]     <DigestMethod Algorithm="http://www.w3.org/2000/09/
           xmldsig#sha1"/>
[m04]     <DigestValue>345x3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
[m05]   </Reference>
[   ] ...
[m06] <Object>
[m07]   <Manifest Id="MyFirstManifest">
[m08]     <Reference>
[m09]     ...
[m10]     </Reference>
[m11]     <Reference>
[m12]     ...
[m13]     </Reference>
[m14]   </Manifest>
[m15] </Object>







Eastlake, et al.            Standards Track                    [Page 12]

RFC 3075          XML-Signature Syntax and Processing         March 2001


3.0 Processing Rules

   The sections below describe the operations to be performed as part of
   signature generation and validation.

3.1 Core Generation

   The REQUIRED steps include the generation of Reference elements and
   the SignatureValue over SignedInfo.

3.1.1 Reference Generation

   For each data object being signed:

   1. Apply the Transforms, as determined by the application, to the
      data object.
   2. Calculate the digest value over the resulting data object.

   3. Create a Reference element, including the (optional)
      identification of the data object, any (optional) transform
      elements, the digest algorithm and the DigestValue.

3.1.2 Signature Generation

   1. Create SignedInfo element with SignatureMethod,
      CanonicalizationMethod and Reference(s).
   2. Canonicalize and then calculate the SignatureValue over SignedInfo
      based on algorithms specified in SignedInfo.
   3. Construct the Signature element that includes SignedInfo,
      Object(s) (if desired, encoding may be different than that used
      for signing), KeyInfo (if required), and SignatureValue.

3.2 Core Validation

   The REQUIRED steps of core validation include (1) reference
   validation, the verification of the digest contained in each
   Reference in SignedInfo, and (2) the cryptographic signature
   validation of the signature calculated over SignedInfo.

   Note, there may be valid signatures that some signature applications
   are unable to validate.  Reasons for this include failure to
   implement optional parts of this specification, inability or
   unwillingness to execute specified algorithms, or inability or
   unwillingness to dereference specified URIs (some URI schemes may
   cause undesirable side effects), etc.






Eastlake, et al.            Standards Track                    [Page 13]

RFC 3075          XML-Signature Syntax and Processing         March 2001


3.2.1 Reference Validation

   For each Reference in SignedInfo:

   1. Canonicalize the SignedInfo element based on the
      CanonicalizationMethod in SignedInfo.
   2. Obtain the data object to be digested.  (The signature application
      may rely upon the identification (URI) and Transforms provided by
      the signer in the Reference element, or it may obtain the content
      through other means such as a local cache.)
   3. Digest the resulting data object using the DigestMethod specified
      in its Reference specification.
   4. Compare the generated digest value against DigestValue in the
      SignedInfo Reference; if there is any mismatch, validation fails.

   Note, SignedInfo is canonicalized in step 1 to ensure the application
   Sees What is Signed, which is the canonical form.  For instance, if
   the CanonicalizationMethod rewrote the URIs (e.g., absolutizing
   relative URIs) the signature processing must be cognizant of this.

3.2.2 Signature Validation

   1. Obtain the keying information from KeyInfo or from an external
      source.
   2. Obtain the canonical form of the SignatureMethod using  the
      CanonicalizationMethod and use the result (and previously obtained
      KeyInfo) to validate the SignatureValue over the SignedInfo
      element.

   Note, KeyInfo (or some transformed version thereof) may be signed via
   a Reference element.  Transformation and validation of this reference
   (3.2.1) is orthogonal to Signature Validation which uses the KeyInfo
   as parsed.

   Additionally, the SignatureMethod URI may have been altered by the
   canonicalization of SignedInfo (e.g., absolutization of relative
   URIs) and it is the canonical form that MUST be used.  However, the
   required canonicalization [XML-C14N] of this specification does not
   change URIs.

4.0 Core Signature Syntax

   The general structure of an XML signature is described in Signature
   Overview (section 2).  This section provides detailed syntax of the
   core signature features.  Features described in this section are
   mandatory to implement unless otherwise indicated.  The syntax is
   defined via DTDs and [XML-Schema] with the following XML preamble,
   declaration, internal entity, and simpleType:



Eastlake, et al.            Standards Track                    [Page 14]

RFC 3075          XML-Signature Syntax and Processing         March 2001


   Schema Definition:

<!DOCTYPE schema
   PUBLIC "-//W3C//DTD XMLSCHEMA 200010//EN"
          "http://www.w3.org/2000/10/XMLSchema.dtd"
  [
   <!ATTLIST schema
     xmlns:ds CDATA #FIXED "http://www.w3.org/2000/09/xmldsig#">
   <!ENTITY dsig 'http://www.w3.org/2000/09/xmldsig#'>
  ]>

<schema xmlns="http://www.w3.org/2000/10/XMLSchema"
      xmlns:ds="&dsig;"
      targetNamespace="&dsig;"
      version="0.1"
      elementFormDefault="qualified">

<!-- Basic Types Defined for Signatures -->

<simpleType name="CryptoBinary">
  <restriction base="binary">
   <encoding value="base64"/>
  </restriction>
</simpleType>
DTD:

<!-- These entity declarations permit the flexible parts of Signature
     content model to be easily expanded -->

<!ENTITY % Object.ANY '(#PCDATA|Signature|SignatureProperties|
                        Manifest)*'>
<!ENTITY % Method.ANY '(#PCDATA|HMACOutputLength)*'>
<!ENTITY % Transform.ANY '(#PCDATA|XPath|XSLT)'>
<!ENTITY % SignatureProperty.ANY '(#PCDATA)*'>
<!ENTITY % Key.ANY '(#PCDATA|KeyName|KeyValue|RetrievalMethod|
           X509Data|PGPData|MgmtData|DSAKeyValue|RSAKeyValue)*'>

4.1 The Signature element

   The Signature element is the root element of an XML Signature.
   Signature elements MUST be laxly schema valid [XML-schema] with
   respect to the following schema definition:
   Schema Definition:

<element name="Signature">
  <complexType>
    <sequence>
      <element ref="ds:SignedInfo"/>



Eastlake, et al.            Standards Track                    [Page 15]

RFC 3075          XML-Signature Syntax and Processing         March 2001


      <element ref="ds:SignatureValue"/>
      <element ref="ds:KeyInfo" minOccurs="0"/>
      <element ref="ds:Object" minOccurs="0" maxOccurs="unbounded"/>
    </sequence>
    <attribute name="Id" type="ID" use="optional"/>
  </complexType>
</element>
DTD:

<!ELEMENT Signature (SignedInfo, SignatureValue, KeyInfo?, Object*)  >
<!ATTLIST Signature
          xmlns  CDATA   #FIXED 'http://www.w3.org/2000/09/xmldsig#'
          Id     ID  #IMPLIED >

4.2 The SignatureValue Element

   The SignatureValue element contains the actual value of the digital
   signature; it is always encoded using base64 [MIME].  While we
   specify a mandatory and optional to implement SignatureMethod
   algorithms, user specified algorithms are permitted.  Schema
   Definition:

   <element name="SignatureValue" type="ds:CryptoBinary"/>
   DTD:

   <!ELEMENT SignatureValue (#PCDATA) >

4.3 The SignedInfo Element

   The structure of SignedInfo includes the canonicalization algorithm,
   a signature algorithm, and one or more references.  The SignedInfo
   element may contain an optional ID attribute that will allow it to be
   referenced by other signatures and objects.

   SignedInfo does not include explicit signature or digest properties
   (such as calculation time, cryptographic device serial number, etc.).
   If an application needs to associate properties with the signature or
   digest, it may include such information in a SignatureProperties
   element within an Object element.
   Schema Definition:

      <element name="SignedInfo">
        <complexType>
          <sequence>
            <element ref="ds:CanonicalizationMethod"/>
            <element ref="ds:SignatureMethod"/>
            <element ref="ds:Reference" maxOccurs="unbounded"/>
          </sequence>



Eastlake, et al.            Standards Track                    [Page 16]

RFC 3075          XML-Signature Syntax and Processing         March 2001


        <attribute name="Id" type="ID" use="optional"/>
        </complexType>
      </element>
      DTD: