rfc3075.txt

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

      <!ELEMENT SignedInfo (CanonicalizationMethod,
             SignatureMethod,  Reference+)  >
   <!ATTLIST SignedInfo
             Id  ID      #IMPLIED>

4.3.1 The CanonicalizationMethod Element

   CanonicalizationMethod is a required element that specifies the
   canonicalization algorithm applied to the SignedInfo element prior to
   performing signature calculations.  This element uses the general
   structure for algorithms described in Algorithm Identifiers and
   Implementation Requirements (section 6.1).  Implementations MUST
   support the REQUIRED Canonical XML [XML-C14N] method.

   Alternatives to the REQUIRED Canonical XML algorithm (section 6.5.2),
   such as Canonical XML with Comments (section 6.5.2) and Minimal
   Canonicalization (the CRLF and charset normalization specified in
   section 6.5.1), may be explicitly specified but are NOT REQUIRED.
   Consequently, their use may not interoperate with other applications
   that do no support the specified algorithm (see XML Canonicalization
   and Syntax Constraint Considerations, section 7).  Security issues
   may also arise in the treatment of entity processing and comments if
   minimal or other non-XML aware canonicalization algorithms are not
   properly constrained (see section 8.2: Only What is "Seen" Should be
   Signed).

   The way in which the SignedInfo element is presented to the
   canonicalization method is dependent on that method.  The following
   applies to the two types of algorithms specified by this document:

      *  Canonical XML [XML-C14N] (with or without comments)
         implementation MUST be provided with an XPath node-set
         originally formed from the document containing the SignedInfo
         and currently indicating the SignedInfo, its descendants, and
         the attribute and namespace nodes of SignedInfo and its
         descendant elements (such that the namespace context and
         similar ancestor information of the SignedInfo is preserved).

      *  Minimal canonicalization implementations MUST be provided with
         the octets that represent the well-formed SignedInfo element,
         from the first character to the last character of the XML
         representation, inclusive.  This includes the entire text of




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


         the start and end tags of the SignedInfo element as well as all
         descendant markup and character data (i.e., the text) between
         those tags.

   We RECOMMEND that resource constrained applications that do not
   implement the Canonical XML [XML-C14N] algorithm and instead choose
   minimal canonicalization (or some other form) be implemented to
   generate Canonical XML as their output serialization so as to easily
   mitigate some of these interoperability and security concerns.
   (While a result might not be the canonical form of the original, it
   can still be in canonical form.)  For instance, such an
   implementation SHOULD (at least) generate standalone XML instances
   [XML].
   Schema Definition:

   <element name="CanonicalizationMethod">
     <complexType>
       <sequence>
         <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
       </sequence>
       <attribute name="Algorithm" type="uriReference" use="required"/>
     </complexType>
   </element>
   DTD:

   <!ELEMENT CanonicalizationMethod %Method.ANY; >
   <!ATTLIST CanonicalizationMethod
             Algorithm CDATA #REQUIRED >

4.3.2 The SignatureMethod Element

   SignatureMethod is a required element that specifies the algorithm
   used for signature generation and validation.  This algorithm
   identifies all cryptographic functions involved in the signature
   operation (e.g., hashing, public key algorithms, MACs, padding,
   etc.).  This element uses the general structure here for algorithms
   described in section 6.1: Algorithm Identifiers and Implementation
   Requirements.  While there is a single identifier, that identifier
   may specify a format containing multiple distinct signature values.
   Schema Definition:

   <element name="SignatureMethod">
     <complexType>
       <sequence>
         <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
       </sequence>
       <attribute name="Algorithm" type="uriReference" use="required"/>
      </complexType>



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


   </element>
   DTD:

   <!ELEMENT SignatureMethod %Method.ANY; >
   <!ATTLIST SignatureMethod
             Algorithm CDATA #REQUIRED >

4.3.3 The Reference Element

   Reference is an element that may occur one or more times.  It
   specifies a digest algorithm and digest value, and optionally an
   identifier of the object being signed, the type of the object, and/or
   a list of transforms to be applied prior to digesting.  The
   identification (URI) and transforms describe how the digested content
   (i.e., the input to the digest method) was created.  The Type
   attribute facilitates the processing of referenced data.  For
   example, while this specification makes no requirements over external
   data, an application may wish to signal that the referent is a
   Manifest.  An optional ID attribute permits a Reference to be
   referenced from elsewhere.
   Schema Definition:

   <element name="Reference">
     <complexType>
       <sequence>
         <element ref="ds:Transforms" minOccurs="0"/>
         <element ref="ds:DigestMethod"/>
         <element ref="ds:DigestValue"/>
       </sequence>
       <attribute name="Id" type="ID" use="optional"/>
       <attribute name="URI" type="uriReference" use="optional"/>
       <attribute name="Type" type="uriReference" use="optional"/>
     </complexType>
   </element>
   DTD:

   <!ELEMENT Reference (Transforms?, DigestMethod, DigestValue)  >
   <!ATTLIST Reference
             Id     ID  #IMPLIED
             URI    CDATA   #IMPLIED
             Type   CDATA   #IMPLIED >

4.3.3.1 The URI Attribute

   The URI attribute identifies a data object using a URI-Reference, as
   specified by RFC2396 [URI].  The set of allowed characters for URI
   attributes is the same as for XML, namely [Unicode].  However, some
   Unicode characters are disallowed from URI references including all



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


   non-ASCII characters and the excluded characters listed in RFC2396
   [URI, section 2.4].  However, the number sign (#), percent sign (%),
   and square bracket characters re-allowed in RFC 2732 [URI-Literal]
   are permitted.  Disallowed characters must be escaped as follows:

   1. Each disallowed character is converted to [UTF-8] as one or more
      bytes.
   2. Any octets corresponding to a disallowed character are escaped
      with the URI escaping mechanism (that is, converted to %HH, where
      HH is the hexadecimal notation of the byte value).
   3. The original character is replaced by the resulting character
      sequence.

   XML signature applications MUST be able to parse URI syntax.  We
   RECOMMEND they be able to dereference URIs in the HTTP scheme.
   Dereferencing a URI in the HTTP scheme MUST comply with the Status
   Code Definitions of [HTTP] (e.g., 302, 305 and 307 redirects are
   followed to obtain the entity-body of a 200 status code response).
   Applications should also be cognizant of the fact that protocol
   parameter and state information, (such as a HTTP cookies, HTML device
   profiles or content negotiation), may affect the content yielded by
   dereferencing a URI.

   If a resource is identified by more than one URI, the most specific
   should be used (e.g.  http://www.w3.org/2000/06/interop-
   pressrelease.html.en instead of http://www.w3.org/2000/06/interop-
   pressrelease).  (See the Reference Validation (section 3.2.1) for a
   further information on reference processing.)

   If the URI attribute is omitted altogether, the receiving application
   is expected to know the identity of the object.  For example, a
   lightweight data protocol might omit this attribute given the
   identity of the object is part of the application context.  This
   attribute may be omitted from at most one Reference in any particular
   SignedInfo, or Manifest.

   The optional Type attribute contains information about the type of
   object being signed.  This is represented as a URI.  For example:

   Type="http://www.w3.org/2000/09/xmldsig#Object"
   Type="http://www.w3.org/2000/09/xmldsig#Manifest"

   The Type attribute applies to the item being pointed at, not its
   contents.  For example, a reference that identifies an Object element
   containing a SignatureProperties element is still of type #Object.
   The type attribute is advisory.  No validation of the type
   information is required by this specification.




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


4.3.3.2 The Reference Processing Model

   Note: XPath is RECOMMENDED.  Signature applications need not conform
   to [XPath] specification in order to conform to this specification.
   However, the XPath data model, definitions (e.g., node-sets) and
   syntax is used within this document in order to describe
   functionality for those that want to process XML-as-XML (instead of
   octets) as part of signature generation.  For those that want to use
   these features, a conformant [XPath] implementation is one way to
   implement these features, but it is not required.  Such applications
   could use a sufficiently functional replacement to a node-set and
   implement only those XPath expression behaviors REQUIRED by this
   specification.  However, for simplicity we generally will use XPath
   terminology without including this qualification on every point.
   Requirements over "XPath nodesets" can include a node-set functional
   equivalent.  Requirements over XPath processing can include
   application behaviors that are equivalent to the corresponding XPath
   behavior.

   The data-type of the result of URI dereferencing or subsequent
   Transforms is either an octet stream or an XPath node-set.

   The Transforms specified in this document are defined with respect to
   the input they require.  The following is the default signature
   application behavior:

      *  If the data object is a an octet stream and the next
         transformrequires a node-set, the signature application MUST
         attempt to parse the octets.

      *  If the data object is a node-set and the next transformrequires
         octets, the signature application MUST attempt to convert the
         node-set to an octet stream using the REQUIRED canonicalization
         algorithm [XML-C14N].

   Users may specify alternative transforms that over-ride these
   defaults in transitions between Transforms that expect different
   inputs.  The final octet stream contains the data octets being
   secured.  The digest algorithm specified by DigestMethod is then
   applied to these data octets, resulting in the DigestValue.

   Unless the URI-Reference is a 'same-document' reference as defined in
   [URI, Section 4.2], the result of dereferencing the URI-Reference
   MUST be an octet stream.  In particular, an XML document identified
   by URI is not parsed by the signature application unless the URI is a
   same-document reference or unless a transformthat requires XML
   parsing is applied (See Transforms (section 4.3.3.1).)




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


   When a fragment is preceded by an absolute or relative URI in the
   URI-Reference, the meaning of the fragment is defined by the
   resource's MIME type.  Even for XML documents, URI dereferencing
   (including the fragment processing) might be done for the signature
   application by a proxy.  Therefore, reference validation might fail
   if fragment processing is not performed in a standard way (as defined
   in the following section for same-document references).
   Consequently, we RECOMMEND that the URI attribute not include
   fragment identifiers and that such processing be specified as an
   additional XPath Transform.

   When a fragment is not preceded by a URI in the URI-Reference, XML
   signature applications MUST support the null URI and barename
   XPointer.  We RECOMMEND support for the same-document XPointers
   '#xpointer(/)' and '#xpointer(id("ID"))' if the application also
   intends to support Minimal Canonicalization or Canonical XML with
   Comments.  (Otherwise URI="#foo" will automatically remove comments
   before the Canonical XML with Comments can even be invoked.)  All
   other support for XPointers is OPTIONAL, especially all support for
   barename and other XPointers in external resources since the
   application may not have control over how the fragment is generated
   (leading to interoperability problems and validation failures).

   The following examples demonstrate what the URI attribute identifies
   and how it is dereferenced: