rfc3075.txt

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

      *  Kent Tamura, IBM
      *  Winchel Todd Vincent III, GSU
      *  Carl Wallace, Corsec Security, Inc.
      *  Greg Whitehead, Signio Inc.

   As are the last call comments from the following:

      *  Dan Connolly, W3C
      *  Paul Biron, Kaiser Permanente, on behalf of the XML Schema WG.
      *  Martin J. Duerst, W3C; and Masahiro Sekiguchi, Fujitsu; on
         behalf of the Internationalization WG/IG.
      *  Jonathan Marsh, Microsoft, on behalf of the Extensible
         Stylesheet Language WG.

2.0 Signature Overview and Examples

   This section provides an overview and examples of XML digital
   signature syntax.  The specific processing is given in Processing
   Rules (section 3).  The formal syntax is found in Core Signature
   Syntax (section 4) and Additional Signature Syntax (section 5).

   In this section, an informal representation and examples are used to
   describe the structure of the XML signature syntax.  This
   representation and examples may omit attributes, details and
   potential features that are fully explained later.

   XML Signatures are applied to arbitrary digital content (data
   objects) via an indirection.  Data objects are digested, the
   resulting value is placed in an element (with other information) and
   that element is then digested and cryptographically signed.  XML
   digital signatures are represented by the Signature element which has




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


   the following structure (where "?" denotes zero or one occurrence;
   "+" denotes one or more occurrences; and "*" denotes zero or more
   occurrences):

      <Signature>
        <SignedInfo>
          (CanonicalizationMethod)
          (SignatureMethod)
          (<Reference (URI=)? >
            (Transforms)?
            (DigestMethod)
            (DigestValue)
          </Reference>)+
        </SignedInfo>
        (SignatureValue)
       (KeyInfo)?
       (Object)*
      </Signature>

   Signatures are related to data objects via URIs [URI].  Within an XML
   document, signatures are related to local data objects via fragment
   identifiers.  Such local data can be included within an enveloping
   signature or can enclose an enveloped signature.  Detached signatures
   are over external network resources or local data objects that
   resides within the same XML document as sibling elements; in this
   case, the signature is neither enveloping (signature is parent) nor
   enveloped (signature is child).  Since a Signature element (and its
   Id attribute value/name) may co-exist or be combined with other
   elements (and their IDs) within a single XML document, care should be
   taken in choosing names such that there are no subsequent collisions
   that violate the ID uniqueness validity constraint [XML].

2.1 Simple Example (Signature, SignedInfo, Methods, and References)

   The following example is a detached signature of the content of the
   HTML4 in XML specification.

[s01] <Signature Id="MyFirstSignature"
       xmlns="http://www.w3.org/2000/09/xmldsig#">
[s02]   <SignedInfo>
[s03]   <CanonicalizationMethod
         Algorithm="http://www.w3.org/TR/2000/CR-xml-c14n-20001026"/>
[s04]   <SignatureMethod
         Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
[s05]   <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/">
[s06]     <Transforms>
[s07]       <Transform Algorithm="http://www.w3.org/TR/2000/
             CR-xml-c14n-20001026"/>



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


[s08]     </Transforms>
[s09]     <DigestMethod Algorithm="http://www.w3.org/2000/09/
           xmldsig#sha1"/>
[s10]     <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
[s11]   </Reference>
[s12] </SignedInfo>
[s13]   <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>
[s14]   <KeyInfo>
[s15a]    <KeyValue>
[s15b]      <DSAKeyValue>
[s15c]        <P>...</P><Q>...</Q><G>...</G><Y>...</Y>
[s15d]      </DSAKeyValue>
[s15e]    </KeyValue>
[s16]   </KeyInfo>
[s17] </Signature>

   [s02-12] The required SignedInfo element is the information that is
   actually signed.  Core validation of SignedInfo consists of two
   mandatory processes: validation of the signature over SignedInfo and
   validation of each Reference digest within SignedInfo.  Note that the
   algorithms used in calculating the SignatureValue are also included
   in the signed information while the SignatureValue element is outside
   SignedInfo.

   [s03] The CanonicalizationMethod is the algorithm that is used to
   canonicalize the SignedInfo element before it is digested as part of
   the signature operation.

   [s04] The SignatureMethod is the algorithm that is used to convert
   the canonicalized SignedInfo into the SignatureValue.  It is a
   combination of a digest algorithm and a key dependent algorithm and
   possibly other algorithms such as padding, for example RSA-SHA1.  The
   algorithm names are signed to resist attacks based on substituting a
   weaker algorithm.  To promote application interoperability we specify
   a set of signature algorithms that MUST be implemented, though their
   use is at the discretion of the signature creator.  We specify
   additional algorithms as RECOMMENDED or OPTIONAL for implementation
   and the signature design permits arbitrary user algorithm
   specification.

   [s05-11] Each Reference element includes the digest method and
   resulting digest value calculated over the identified data object.
   It also may include transformations that produced the input to the
   digest operation.  A data object is signed by computing its digest
   value and a signature over that value.  The signature is later
   checked via reference and signature validation.





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


   [s14-16] KeyInfo indicates the key to be used to validate the
   signature.  Possible forms for identification include certificates,
   key names, and key agreement algorithms and information -- we define
   only a few.  KeyInfo is optional for two reasons.  First, the signer
   may not wish to reveal key information to all document processing
   parties.  Second, the information may be known within the
   application's context and need not be represented explicitly.  Since
   KeyInfo is outside of SignedInfo, if the signer wishes to bind the
   keying information to the signature, a Reference can easily identify
   and include the KeyInfo as part of the signature.

2.1.1 More on Reference

[s05]   <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/">
[s06]     <Transforms>
[s07]       <Transform
             Algorithm="http://www.w3.org/TR/2000/
             CR-xml-c14n-20001026"/>
[s08]     </Transforms>
[s09]     <DigestMethod Algorithm="http://www.w3.org/2000/09/
           xmldsig#sha1"/>
[s10]     <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
[s11]   </Reference>

   [s05] The optional URI attribute of Reference identifies the data
   object to be signed.  This attribute may be omitted on at most one
   Reference in a Signature.  (This limitation is imposed in order to
   ensure that references and objects may be matched unambiguously.)

   [s05-08] This identification, along with the transforms, is a
   description provided by the signer on how they obtained the signed
   data object in the form it was digested (i.e., the digested content).
   The verifier may obtain the digested content in another method so
   long as the digest verifies.  In particular, the verifier may obtain
   the content from a different location such as a local store than that
   specified in the URI.

   [s06-08] Transforms is an optional ordered list of processing steps
   that were applied to the resource's content before it was digested.
   Transforms can include operations such as canonicalization,
   encoding/decoding (including compression/inflation), XSLT and XPath.
   XPath transforms permit the signer to derive an XML document that
   omits portions of the source document.  Consequently those excluded
   portions can change without affecting signature validity.  For
   example, if the resource being signed encloses the signature itself,
   such a transform must be used to exclude the signature value from its
   own computation.  If no Transforms element is present, the resource's
   content is digested directly.  While we specify mandatory (and



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


   optional) canonicalization and decoding algorithms, user specified
   transforms are permitted.

   [s09-10] DigestMethod is the algorithm applied to the data after
   Transforms is applied (if specified) to yield the DigestValue.  The
   signing of the DigestValue is what binds a resources content to the
   signer's key.

2.2 Extended Example (Object and SignatureProperty)

   This specification does not address mechanisms for making statements
   or assertions.  Instead, this document defines what it means for
   something to be signed by an XML Signature (message authentication,
   integrity, and/or signer authentication).  Applications that wish to
   represent other semantics must rely upon other technologies, such as
   [XML, RDF].  For instance, an application might use a foo:assuredby
   attribute within its own markup to reference a Signature element.
   Consequently, it's the application that must understand and know how
   to make trust decisions given the validity of the signature and the
   meaning of assuredby syntax.  We also define a SignatureProperties
   element type for the inclusion of assertions about the signature
   itself (e.g., signature semantics, the time of signing or the serial
   number of hardware used in cryptographic processes).  Such assertions
   may be signed by including a Reference for the SignatureProperties in
   SignedInfo.  While the signing application should be very careful
   about what it signs (it should understand what is in the
   SignatureProperty) a receiving application has no obligation to
   understand that semantic (though its parent trust engine may wish
   to).  Any content about the signature generation may be located
   within the SignatureProperty element.  The mandatory Target attribute
   references the Signature element to which the property applies.

   Consider the preceding example with an additional reference to a
   local Object that includes a SignatureProperty element.  (Such a
   signature would not only be detached [p02] but enveloping [p03].)

[   ]  <Signature Id="MySecondSignature" ...>
[p01]  <SignedInfo>
[   ]   ...
[p02]   <Reference URI="http://www.w3.org/TR/xml-stylesheet/">
[   ]   ...
[p03]   <Reference URI="#AMadeUpTimeStamp"
[p04]         Type="http://www.w3.org/2000/09/
                    xmldsig#SignatureProperties">
[p05]    <DigestMethod Algorithm="http://www.w3.org/2000/09/
          xmldsig#sha1"/>
[p06]    <DigestValue>k3453rvEPO0vKtMup4NbeVu8nk=</DigestValue>
[p07]   </Reference>



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


[p08]  </SignedInfo>
[p09]  ...
[p10]  <Object>
[p11]   <SignatureProperties>
[p12]     <SignatureProperty Id="AMadeUpTimeStamp"
           Target="#MySecondSignature">
[p13]        <timestamp xmlns="http://www.ietf.org/rfc3075.txt">
[p14]          <date>19990908</date>
[p15]          <time>14:34:34:34</time>
[p16]        </timestamp>
[p17]     </SignatureProperty>
[p18]   </SignatureProperties>
[p19]  </Object>
[p20]</Signature>

   [p04] The optional Type attribute of Reference provides information
   about the resource identified by the URI.  In particular, it can
   indicate that it is an Object, SignatureProperty, or Manifest
   element.  This can be used by applications to initiate special
   processing of some Reference elements.  References to an XML data
   element within an Object element SHOULD identify the actual element
   pointed to.  Where the element content is not XML (perhaps it is
   binary or encoded data) the reference should identify the Object and
   the Reference Type, if given, SHOULD indicate Object.  Note that Type
   is advisory and no action based on it or checking of its correctness
   is required by core behavior.

   [p10] Object is an optional element for including data objects within
   the signature element or elsewhere.  The Object can be optionally
   typed and/or encoded.

   [p11-18] Signature properties, such as time of signing, can be
   optionally signed by identifying them from within a Reference.
   (These properties are traditionally called signature "attributes"
   although that term has no relationship to the XML term "attribute".)

2.3 Extended Example (Object and Manifest)