RFC3075 - XML-Signature Syntax and Processing(2)

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:

URI="http://example.com/bar.xml"
Identifies the octets that represent the external resource
'http//example.com/bar.xml', that is probably XML document
given its file extension.

URI="http://example.com/bar.xml#chapter1"
Identifies the element with ID attribute value 'chapter1' of
the external XML resource 'http://example.com/bar.xml',
provided as an octet stream. Again, for the sake of
interoperability, the element identified as 'chapter1' should
be obtained using an XPath transformrather than a URI fragment
(barename XPointer resolution in external resources is not
REQUIRED in this specification).

URI=""
Identifies the nodeset (minus any comment nodes) of the XML
resource containing the signature

URI="#chapter1"
Identifies a nodeset containing the element with ID attribute
value 'chapter1' of the XML resource containing the signature.
XML Signature (and its applications) modify this nodeset to
include the element plus all descendents including namespaces
and attributes -- but not comments.

4.3.3.3 Same-Document URI-References

Dereferencing a same-document reference MUST result in an XPath
node-set suitable for use by Canonical XML. Specifically,
dereferencing a null URI (URI="") MUST result in an XPath node-set
that includes every non-comment node of the XML document containing
the URI attribute. In a fragment URI, the characters after the
number sign ('#') character conform to the XPointer syntax [Xptr].
When processing an XPointer, the application MUST behave as if the
root node of the XML document containing the URI attribute were used
to initialize the XPointer evaluation context. The application MUST
behave as if the result of XPointer processing were a node-set
derived from the resultant location-set as follows:

1. discard point nodes
2. replace each range node with all XPath nodes having full or
partial content within the range
3. replace the root node with its children (if it is in the node-set)
4. replace any element node E with E plus all descendants of E (text,
comment, PI, element) and all namespace and attribute nodes of E
and its descendant elements.
5. if the URI is not a full XPointer, then delete all comment nodes

The second to last replacement is necessary because XPointer
typically indicates a subtree of an XML document's parse tree using
just the element node at the root of the subtree, whereas Canonical
XML treats a node-set as a set of nodes in which absence of
descendant nodes results in absence of their representative text from
the canonical form.

The last step is performed for null URIs, barename XPointers and
child sequence XPointers. To retain comments while selecting an
element by an identifier ID, use the following full XPointer:
URI='#xpointer(id("ID"))'. To retain comments while selecting the
entire document, use the following full XPointer: URI='#xpointer(/)'.
This XPointer contains a simple XPath expression that includes the
root node, which the second to last step above replaces with all
nodes of the parse tree (all descendants, plus all attributes, plus
all namespaces nodes).

4.3.3.4 The Transforms Element

The optional Transforms element contains an ordered list of Transform
elements; these describe how the signer obtained the data object that
was digested. The output of each Transform serves as input to the
next Transform. The input to the first Transform is the result of
dereferencing the URI attribute of the Reference element. The output
from the last Transform is the input for the DigestMethod algorithm.
When transforms are applied the signer is not signing the native
(original) document but the resulting (transformed) document. (See
Only What is Signed is Secure (section 8.1).)

Each Transform consists of an Algorithm attribute and content
parameters, if any, appropriate for the given algorithm. The
Algorithm attribute value specifies the name of the algorithm to be
performed, and the Transform content provides additional data to
govern the algorithm's processing of the transform input. (See
Algorithm Identifiers and Implementation Requirements (section 6).)

As described in The Reference Processing Model (section 4.3.3.2),
some transforms take an XPath node-set as input, while others require
an octet stream. If the actual input matches the input needs of the
transform, then the transform operates on the unaltered input. If
the transform input requirement differs from the format of the actual
input, then the input must be converted.

Some Transform may require explicit MIME type, charset (IANA
registered "character set"), or other such information concerning the
data they are receiving from an earlier Transform or the source data,
although no Transform algorithm specified in this document needs such
explicit information. Such data characteristics are provided as
parameters to the Transform algorithm and should be described in the
specification for the algorithm.

Examples of transforms include but are not limited to base64 decoding
[MIME], canonicalization [XML-C14N], XPath filtering [XPath], and
XSLT [XSLT]. The generic definition of the Transform element also
allows application-specific transform algorithms. For example, the
transform could be a decompression routine given by a Java class
appearing as a base64 encoded parameter to a Java Transform
algorithm. However, applications should refrain from using
application-specific transforms if they wish their signatures to be
verifiable outside of their application domain. Transform Algorithms
(section 6.6) defines the list of standard transformations.
Schema Definition:

<element name="Transforms">
<complexType>
<sequence>
<element ref="ds:Transform" maxOccurs="unbounded"/>
</sequence>
</complexType>
</element>

<element name="Transform">
<complexType>
<choice maxOccurs="unbounded">
<any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
<element name="XSLT" type="string"/>

<element name="XPath" type="string"/>
</choice>
<attribute name="Algorithm" type="uriReference" use="required"/>
</complexType>
</element>
DTD:

<!ELEMENT Transforms (Transform+)>

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

<!ELEMENT XPath (#PCDATA) >
<!ELEMENT XSLT (#PCDATA) >

4.3.3.5 The DigestMethod Element

DigestMethod is a required element that identifies the digest
algorithm to be applied to the signed object. This element uses the
general structure here for algorithms specified in Algorithm
Identifiers and Implementation Requirements (section 6.1).

If the result of the URI dereference and application of Transforms is
an XPath node-set (or sufficiently functional replacement implemented
by the application) then it must be converted as described in the
Reference Processing Model (section 4.3.3.2). If the result of URI
dereference and application of Transforms is an octet stream, then no
conversion occurs (comments might be present if the Minimal
Canonicalization or Canonical XML with Comments was specified in the
Transforms). The digest algorithm is applied to the data octets of
the resulting octet stream.
Schema Definition:

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

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

4.3.3.6 The DigestValue Element

DigestValue is an element that contains the encoded value of the
digest. The digest is always encoded using base64 [MIME].
Schema Definition:

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

<!ELEMENT DigestValue (#PCDATA) >


4.4 The KeyInfo Element

KeyInfo is an optional element that enables the recipient(s) to
obtain the key needed to validate the signature. KeyInfo may contain
keys, names, certificates and other public key management
information, such as in-band key distribution or key agreement data.
This specification defines a few simple types but applications may
place their own key identification and exchange semantics within this
element type through the XML-namespace facility [XML-ns].

If KeyInfo is omitted, the recipient is expected to be able to
identify the key based on application context information. Multiple
declarations within KeyInfo refer to the same key. While
applications may define and use any mechanism they choose through
inclusion of elements from a different namespace, compliant versions
MUST implement KeyValue (section 4.4.2) and SHOULD implement
RetrievalMethod (section 4.4.3).

The following list summarizes the KeyInfo types defined by this
specification; these can be used within the RetrievalMethod Type
attribute to describe the remote KeyInfo structure as represented as
an octect stream.

* http://www.w3.org/2000/09/xmldsig#X509Data
* http://www.w3.org/2000/09/xmldsig#PGPData
* http://www.w3.org/2000/09/xmldsig#SPKIData
* http://www.w3.org/2000/09/xmldsig#MgmtData

In addition to the types above for which we define structures, we
specify one additional type to indicate a binary X.509 Certificate

* http://www.w3.org/2000/09/xmldsig#rawX509Certificate

Schema Definition:

<element name="KeyInfo">
<complexType>
<choice maxOccurs="unbounded">
<any processContents="lax" namespace="##other" minOccurs="0"
maxOccurs="unbounded"/>
<element name="KeyName" type="string"/>
<element ref="ds:KeyValue"/>
<element ref="ds:RetrievalMethod"/>
<element ref="ds:X509Data"/>
<element ref="ds:PGPData"/>
<element ref="ds:SPKIData"/>
<element name="MgmtData" type="string"/>
</choice>
<attribute name="Id" type="ID" use="optional"/>
</complexType>
</element>
DTD:

<!ELEMENT KeyInfo %Key.ANY; >
<!ATTLIST KeyInfo
Id ID #IMPLIED >

4.4.1 The KeyName Element

The KeyName element contains a string value which may be used by the
signer to communicate a key identifier to the recipient. Typically,
KeyName contains an identifier related to the key pair used to sign
the message, but it may contain other protocol-related information
that indirectly identifies a key pair. (Common uses of KeyName
include simple string names for keys, a key index, a distinguished
name (DN), an email address, etc.)

Schema Definition:


DTD:

<!ELEMENT KeyName (#PCDATA) >

4.4.2 The KeyValue Element

The KeyValue element contains a single public key that may be useful
in validating the signature. Structured formats for defining DSA
(REQUIRED) and RSA (RECOMMENDED) public keys are defined in Signature
Algorithms (section 6.4).
Schema Definition:

<element name="KeyValue">
<complexType mixed="true">
<choice>
<any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
<element ref="ds:DSAKeyValue"/>
<element ref="ds:RSAKeyValue"/>
</choice>
</complexType>
</element>

DTD:
<!ELEMENT KeyValue %Key.ANY; >

4.4.3 The RetrievalMethod Element

A RetrievalMethod element within KeyInfo is used to convey a
reference to KeyInfo information that is stored at another location.
For example, several signatures in a document might use a key
verified by an X.509v3 certificate chain appearing once in the
document or remotely outside the document; each signature's KeyInfo
can reference this chain using a single RetrievalMethod element
instead of including the entire chain with a sequence of
X509Certificate elements.

RetrievalMethod uses the same syntax and dereferencing behavior as
Reference's URI (section 4.3.3.1) and The Reference Processing Model
(section 4.3.3.2) except that there is no DigestMethod or DigestValue
child elements and presence of the URI is mandatory. Note, if the
result of dereferencing and transforming the specified URI is a node
set, then it may need to be to be canonicalized. All of the KeyInfo
types defined by this specification (section 4.4) represent octets,

consequently the Signature application is expected to attempt to
canonicalize the nodeset via the The Reference Processing Model
(section 4.3.3.2)

Type is an optional identifier for the type of data to be retrieved.
Schema Definition

<element name="RetrievalMethod">
<complexType>
<sequence>
<element ref="ds:Transforms" minOccurs="0"/>
</sequence>
<attribute name="URI" type="uriReference"/>
<attribute name="Type" type="uriReference" use="optional"/>
</complexType>
</element>
DTD

<!ELEMENT RetrievalMethod (Transforms?) >
<!ATTLIST RetrievalMethod
URI CDATA #REQUIRED
Type CDATA #IMPLIED >

4.4.4 The X509Data Element

Identifier
Type="http://www.w3.org/2000/09/xmldsig#X509Data"
(this can be used within a RetrievalMethod or Reference element
to identify the referent's type)

An X509Data element within KeyInfo contains one or more identifiers
of keys or X509 certificates (or certificates' identifiers or
revocation lists). Five types of X509Data are defined

1. The X509IssuerSerial element, which contains an X.509 issuer
distinguished name/serial number pair that SHOULD be compliant
with RFC2253 [LDAP-DN],
2. The X509SubjectName element, which contains an X.509 subject
distinguished name that SHOULD be compliant with RFC2253 [LDAP-
DN],
3. The X509SKI element, which contains an X.509 subject key
identifier value.
4. The X509Certificate element, which contains a base64-encoded
[X509v3] certificate, and
5. The X509CRL element, which contains a base64-encoded certificate
revocation list (CRL) [X509v3].

Multiple declarations about a single certificate (e.g., a
X509SubjectName and X509IssuerSerial element) MUST be grouped inside
a single X509Data element; multiple declarations about the same key
but different certificates (related to that single key) MUST be
grouped within a single KeyInfo element but MAY occur in multiple
X509Data elements. For example, the following block contains two
pointers to certificate-A (issuer/serial number and SKI) and a single
reference to certificate-B (SubjectName) and also shows use of
certificate elements

<KeyInfo>
<X509Data> 
<X509IssuerSerial>
<X509IssuerName>CN=TAMURA Kent, OU=TRL, O=IBM,
L=Yamato-shi, ST=Kanagawa, C=JP</X509IssuerName>
<X509SerialNumber>12345678</X509SerialNumber>
</X509IssuerSerial>
<X509SKI>31d97bd7</X509SKI>
</X509Data>
<X509Data> 
<X509SubjectName>Subject of Certificate B</X509SubjectName>
</X509Data> 

<X509Certificate>MIICXTCCA..</X509Certificate>

<X509Certificate>MIICPzCCA...</X509Certificate>

<X509Certificate>MIICSTCCA...</X509Certificate>
</X509Data>
</KeyInfo>

Note, there is no direct provision for a PKCS#7 encoded "bag" of
certificates or CRLs. However, a set of certificates or a CRL can
occur within an X509Data element and multiple X509Data elements can
occur in a KeyInfo. Whenever multiple certificates occur in an
X509Data element, at least one such certificate must contain the
public key which verifies the signature.
Schema Definition

<element name="X509Data">
<complexType>
<choice>
<sequence maxOccurs="unbounded">
<choice>
<element ref="ds:X509IssuerSerial"/>
<element name="X509SKI" type="ds:CryptoBinary"/>
<element name="X509SubjectName" type="string"/>

<element name="X509Certificate" type="ds:CryptoBinary"/>
</choice>
</sequence>
<element name="X509CRL" type="ds:CryptoBinary"/>
</choice>
</complexType>
</element>

<element name="X509IssuerSerial">
<complexType>
<sequence>
<element name="X509IssuerName" type="string"/>
<element name="X509SerialNumber" type="integer"/>
</sequence>
</complexType>
</element>

DTD

<!ELEMENT X509Data ((X509IssuerSerial | X509SKI | X509SubjectName |
X509Certificate)+ | X509CRL)>
<!ELEMENT X509IssuerSerial (X509IssuerName, X509SerialNumber) >
<!ELEMENT X509IssuerName (#PCDATA) >
<!ELEMENT X509SubjectName (#PCDATA) >
<!ELEMENT X509SerialNumber (#PCDATA) >
<!ELEMENT X509SKI (#PCDATA) >
<!ELEMENT X509Certificate (#PCDATA) >
<!ELEMENT X509CRL (#PCDATA) >

4.4.5 The PGPData element

Identifier
Type="http://www.w3.org/2000/09/xmldsig#PGPData"
(this can be used within a RetrievalMethod or Reference element
to identify the referent's type)

The PGPData element within KeyInfo is used to convey information
related to PGP public key pairs and signatures on such keys. The
PGPKeyID's value is a string containing a standard PGP public key
identifier as defined in [PGP, section 11.2]. The PGPKeyPacket
contains a base64-encoded Key Material Packet as defined in [PGP,
section 5.5]. Other sub-types of the PGPData element may be defined
by the OpenPGP working group.
Schema Definition:

<element name="PGPData">
<complexType>
<choice>

<any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
<sequence>
<element name="PGPKeyID" type="string"/>
<element name="PGPKeyPacket" type="ds:CryptoBinary"/>
</sequence>
</choice>
</complexType>
</element>

DTD:

<!ELEMENT PGPData (PGPKeyID, PGPKeyPacket) >
<!ELEMENT PGPKeyPacket (#PCDATA) >
<!ELEMENT PGPKeyID (#PCDATA) >

4.4.6 The SPKIData element

Identifier
Type="http://www.w3.org/2000/09/xmldsig#SPKIData"
(this can be used within a RetrievalMethod or Reference element
to identify the referent's type)

The SPKIData element within KeyInfo is used to convey information
related to SPKI public key pairs, certificates and other SPKI data.
The content of this element type is expected to be a Canonical S-
expression.
Schema Definition:

<element name="SPKIData" type="string"/>
DTD:

<!ELEMENT SPKIData (#PCDATA) >

4.4.7 The MgmtData element

Identifier
Type="http://www.w3.org/2000/09/xmldsig#MgmtData"
(this can be used within a RetrievalMethod or Reference element
to identify the referent's type)

The MgmtData element within KeyInfo is a string value used to convey
in-band key distribution or agreement data. For example, DH key
exchange, RSA key encryption, etc.
Schema Definition:


DTD:

<!ELEMENT MgmtData (#PCDATA)>

4.5 The Object Element

Identifier
Type="http://www.w3.org/2000/09/xmldsig#Object"
(this can be used within a Reference element to identify the
referent's type)

Object is an optional element that may occur one or more times. When
present, this element may contain any data. The Object element may
include optional MIME type, ID, and encoding attributes.

The MimeType attribute is an optional attribute which describes the
data within the Object. This is a string with values defined by
[MIME]. For example, if the Object contains XML, the MimeType could
be text/xml. This attribute is purely advisory; no validation of the
MimeType information is required by this specification.

The Object's Id is commonly referenced from a Reference in
SignedInfo, or Manifest. This element is typically used for
enveloping signatures where the object being signed is to be included
in the signature element. The digest is calculated over the entire
Object element including start and end tags.

The Object's Encoding attributed may be used to provide a URI that
identifies the method by which the object is encoded (e.g., a binary
file).

Note, if the application wishes to exclude the <Object> tags from the
digest calculation the Reference must identify the actual data object
(easy for XML documents) or a transform must be used to remove the
Object tags (likely where the data object is non-XML). Exclusion of
the object tags may be desired for cases where one wants the
signature to remain valid if the data object is moved from inside a
signature to outside the signature (or vice-versa), or where the
content of the Object is an encoding of an original binary document
and it is desired to extract and decode so as to sign the original
bitwise representation.
Schema Definition:

<element name="Object">
<complexType mixed="true">
<sequence maxOccurs="unbounded">
<any namespace="##any" processContents="lax"/>

</sequence>
<attribute name="Id" type="ID" use="optional"/>
<attribute name="MimeType" type="string" use="optional"/>

<attribute name="Encoding" type="uriReference" use="optional"/>
</complexType>
</element>
DTD:

<!ELEMENT Object %Object.ANY; >
<!ATTLIST Object
Id ID #IMPLIED
MimeType CDATA #IMPLIED
Encoding CDATA #IMPLIED >

5.0 Additional Signature Syntax

This section describes the optional to implement Manifest and
SignatureProperties elements and describes the handling of XML
processing instructions and comments. With respect to the elements
Manifest and SignatureProperties this section specifies syntax and
little behavior -- it is left to the application. These elements can
appear anywhere the parent's content model permits; the Signature
content model only permits them within Object.

5.1 The Manifest Element

Identifier
Type="http://www.w3.org/2000/09/xmldsig#Manifest"
(this can be used within a Reference element to identify the
referent's type)

The Manifest element provides a list of References. The difference
from the list in SignedInfo is that it is application defined which,
if any, of the digests are actually checked against the objects
referenced and what to do if the object is inaccessible or the digest
compare fails. If a Manifest is pointed to from SignedInfo, the
digest over the Manifest itself will be checked by the core signature
validation behavior. The digests within such a Manifest are checked
at the application's discretion. If a Manifest is referenced from
another Manifest, even the overall digest of this two level deep
Manifest might not be checked.
Schema Definition:

<element name="Manifest">
<complexType>
<sequence>
<element ref="ds:Reference" maxOccurs="unbounded"/>

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

<!ELEMENT Manifest (Reference+) >
<!ATTLIST Manifest
Id ID #IMPLIED >

5.2 The SignatureProperties Element

Identifier
Type="http://www.w3.org/2000/09/xmldsig#SignatureProperties"
(this can be used within a Reference element to identify the
referent's type)

Additional information items concerning the generation of the
signature(s) can be placed in a SignatureProperty element (i.e.,
date/time stamp or the serial number of cryptographic hardware used
in signature generation).
Schema Definition:

<element name="SignatureProperties">
<complexType>
<sequence>
<element ref="ds:SignatureProperty" maxOccurs="unbounded"/>
</sequence>
<attribute name="Id" type="ID" use="optional"/>
</complexType>
</element>

<element name="SignatureProperty">
<complexType mixed="true">
<choice minOccurs="0" maxOccurs="unbounded">
<any namespace="##other" processContents="lax" minOccurs="0"
maxOccurs="unbounded"/>
</choice>
<attribute name="Target" type="uriReference" use="required"/>
<attribute name="Id" type="ID" use="optional"/>
</complexType>
</element>
DTD:

<!ELEMENT SignatureProperties (SignatureProperty+) >
<!ATTLIST SignatureProperties
Id ID #IMPLIED >

<!ELEMENT SignatureProperty %SignatureProperty.ANY >
<!ATTLIST SignatureProperty
Target CDATA #REQUIRED
Id ID #IMPLIED >

5.3 Processing Instructions in Signature Elements

No XML processing instructions (PIs) are used by this specification.

Note that PIs placed inside SignedInfo by an application will be
signed unless the CanonicalizationMethod algorithm discards them.
(This is true for any signed XML content.) All of the
CanonicalizationMethods specified within this specification retain
PIs. When a PI is part of content that is signed (e.g., within
SignedInfo or referenced XML documents) any change to the PI will
obviously result in a signature failure.

5.4 Comments in Signature Elements

XML comments are not used by this specification.

Note that unless CanonicalizationMethod removes comments within
SignedInfo or any other referenced XML (which [XML-C14N] does), they
will be signed. Consequently, if they are retained, a change to the
comment will cause a signature failure. Similarly, the XML signature
over any XML data will be sensitive to comment changes unless a
comment-ignoring canonicalization/transform method, such as the
Canonical XML [XML-C14N], is specified.

6.0 Algorithms

This section identifies algorithms used with the XML digital
signature specification. Entries contain the identifier to be used
in Signature elements, a reference to the formal specification, and
definitions, where applicable, for the representation of keys and the
results of cryptographic operations.

6.1 Algorithm Identifiers and Implementation Requirements

Algorithms are identified by URIs that appear as an attribute to the
element that identifies the algorithms' role (DigestMethod,
Transform, SignatureMethod, or CanonicalizationMethod). All
algorithms used herein take parameters but in many cases the
parameters are implicit. For example, a SignatureMethod is
implicitly given two parameters: the keying info and the output of
CanonicalizationMethod. Explicit additional parameters to an
algorithm appear as content elements within the algorithm role

element. Such parameter elements have a descriptive element name,
which is frequently algorithm specific, and MUST be in the XML
Signature namespace or an algorithm specific namespace.

This specification defines a set of algorithms, their URIs, and
requirements for implementation. Requirements are specified over
implementation, not over requirements for signature use.
Furthermore, the mechanism is extensible, alternative algorithms may
be used by signature applications.

(Note that the normative identifier is the complete URI in the table
though they are sometimes abbreviated in XML syntax (e.g.,
"&dsig;base64").)

Algorithm Type
Algorithm - Requirements - Algorithm URI
Digest
SHA1 - REQUIRED - &dsig;sha1
Encoding
base64 - REQUIRED - &dsig;base64
MAC
HMAC-SHA1 - REQUIRED - &dsig;hmac-sha1
Signature
DSAwithSHA1(DSS) - REQUIRED - &dsig;dsa-sha1
RSAwithSHA1 - RECOMMENDED - &dsig;rsa-sha1
Canonicalization
minimal - RECOMMENDED - &dsig;minimal
Canonical XML with Comments - RECOMMENDED -
http://www.w3.org/TR/2000/CR-xml-c14n-20001026#WithComments
Canonical XML (omits comments) - REQUIRED -
http://www.w3.org/TR/2000/CR-xml-c14n-20001026
Transform
XSLT - OPTIONAL - http://www.w3.org/TR/1999/REC-xslt-19991116
XPath - RECOMMENDED -
http://www.w3.org/TR/1999/REC-xpath-19991116
Enveloped Signature* - REQUIRED - &dsig;enveloped-signature

* The Enveloped Signature transform removes the Signature element
from the calculation of the signature when the signature is within
the content that it is being signed. This MAY be implemented via the
RECOMMENDED XPath specification specified in 6.6.4: Enveloped
Signature Transform; it MUST have the same effect as that specified
by the XPath Transform.

6.2 Message Digests

Only one digest algorithm is defined herein. However, it is expected
that one or more additional strong digest algorithms will be
developed in connection with the US Advanced Encryption Standard
effort. Use of MD5 [MD5] is NOT RECOMMENDED because recent advances
in cryptography have cast doubt on its strength.

6.2.1 SHA-1

Identifier:
http://www.w3.org/2000/09/xmldsig#sha1

The SHA-1 algorithm [SHA-1] takes no explicit parameters. An example
of an SHA-1 DigestAlg element is:
<DigestMethod Algorithm="&dsig;sha1"/>

A SHA-1 digest is a 160-bit string. The content of the DigestValue
element shall be the base64 encoding of this bit string viewed as a
20-octet octet stream. For example, the DigestValue element for the
message digest:
A9993E36 4706816A BA3E2571 7850C26C 9CD0D89D

from Appendix A of the SHA-1 standard would be:
<DigestValue>qZk+NkcGgWq6PiVxeFDCbJzQ2J0=</DigestValue>

6.3 Message Authentication Codes

MAC algorithms take two implicit parameters, their keying material
determined from KeyInfo and the octet stream output by
CanonicalizationMethod. MACs and signature algorithms are
syntactically identical but a MAC implies a shared secret key.

6.3.1 HMAC

Identifier:
http://www.w3.org/2000/09/xmldsig#hmac-sha1

The HMAC algorithm (RFC2104 [HMAC]) takes the truncation length in
bits as a parameter; if the parameter is not specified then all the
bits of the hash are output. An example of an HMAC SignatureMethod
element:

<SignatureMethod Algorithm="&dsig;hmac-sha1">
<HMACOutputLength>128</HMACOutputLength>
</SignatureMethod>

The output of the HMAC algorithm is ultimately the output (possibly
truncated) of the chosen digest algorithm. This value shall be
base64 encoded in the same straightforward fashion as the output of
the digest algorithms. Example: the SignatureValue element for the
HMAC-SHA1 digest

9294727A 3638BB1C 13F48EF8 158BFC9D

from the test vectors in [HMAC] would be

<SignatureValue>kpRyejY4uxwT9I74FYv8nQ==</SignatureValue>
Schema Definition:

<element name="HMACOutputLength" type="integer"/>
DTD:

<!ELEMENT HMACOutputLength (#PCDATA)>

6.4 Signature Algorithms

Signature algorithms take two implicit parameters, their keying
material determined from KeyInfo and the octet stream output by
CanonicalizationMethod. Signature and MAC algorithms are
syntactically identical but a signature implies public key
cryptography.

6.4.1 DSA

Identifier:
http://www.w3.org/2000/09/xmldsig#dsa-sha1

The DSA algorithm [DSS] takes no explicit parameters. An example of
a DSA SignatureMethod element is:

<SignatureMethod Algorithm="&dsig;dsa"/>

The output of the DSA algorithm consists of a pair of integers
usually referred by the pair (r, s). The signature value consists of
the base64 encoding of the concatenation of two octet-streams that
respectively result from the octet-encoding of the values r and s.
Integer to octet-stream conversion must be done according to the
I2OSP operation defined in the RFC2437 [PKCS1] specification with a
k parameter equal to 20. For example, the SignatureValue element for
a DSA signature (r, s) with values specified in hexadecimal:

r = 8BAC1AB6 6410435C B7181F95 B16AB97C 92B341C0
s = 41E2345F 1F56DF24 58F426D1 55B4BA2D B6DCD8C8

from the example in Appendix 5 of the DSS standard would be

<SignatureValue>
i6watmQQQ1y3GB+VsWq5fJKzQcBB4jRfH1bfJFj0JtFVtLotttzYyA==</SignatureValue>

DSA key values have the following set of fields: P, Q, G and Y are
mandatory when appearing as a key value, J, seed and pgenCounter are
optional but should be present. (The seed and pgenCounter fields
must appear together or be absent). All parameters are encoded as
base64 [MIME] values.
Schema:

<element name="DSAKeyValue">
<complexType>
<sequence>
<sequence>
<element name="P" type="ds:CryptoBinary"/>
<element name="Q" type="ds:CryptoBinary"/>
<element name="G" type="ds:CryptoBinary"/>
<element name="Y" type="ds:CryptoBinary"/>
<element name="J" type="ds:CryptoBinary" minOccurs="0"/>
</sequence>
<sequence minOccurs="0">
<element name="Seed" type="ds:CryptoBinary"/>
<element name="PgenCounter" type="ds:CryptoBinary"/>
</sequence>
</sequence>
</complexType>
</element>
DTD:

<!ELEMENT DSAKeyValue (P, Q, G, Y, J?, (Seed, PgenCounter)?) >
<!ELEMENT P (#PCDATA) >
<!ELEMENT Q (#PCDATA) >
<!ELEMENT G (#PCDATA) >
<!ELEMENT Y (#PCDATA) >
<!ELEMENT J (#PCDATA) >
<!ELEMENT Seed (#PCDATA) >
<!ELEMENT PgenCounter (#PCDATA) >

6.4.2 PKCS1

Identifier:
http://www.w3.org/2000/09/xmldsig#rsa-sha1

Arbitrary-length integers (e.g., "bignums" such as RSA modulii) are
represented in XML as octet strings. The integer value is first
converted to a "big endian" bitstring. The bitstring is then padded

with leading zero bits so that the total number of bits == 0 mod 8
(so that there are an even number of bytes). If the bitstring
contains entire leading bytes that are zero, these are removed (so
the high-order byte is always non-zero). This octet string is then
base64 [MIME] encoded. (The conversion from integer to octet string
is equivalent to IEEE 1363's I2OSP [1363] with minimal length).

The expression "RSA algorithm" as used in this document refers to the
RSASSA-PKCS1-v1_5 algorithm described in RFC2437 [PKCS1]. The RSA
algorithm takes no explicit parameters. An example of an RSA
SignatureMethod element is: <SignatureMethod Algorithm="&dsig;rsa-
sha1"/>

The SignatureValue content for an RSA signature is the base64 [MIME]
encoding of the octet string computed as per RFC2437 [PKCS1, section
8.1.1: Signature generation for the RSASSA-PKCS1-v1_5 signature
scheme]. As specified in the EMSA-PKCS1-V1_5-ENCODE function RFC
2437 [PKCS1, section 9.2.1], the value input to the signature
function MUST contain a pre-pended algorithm object identifier for
the hash function, but the availability of an ASN.1 parser and
recognition of OIDs is not required of a signature verifier. The
PKCS#1 v1.5 representation appears as:

CRYPT (PAD (ASN.1 (OID, DIGEST (data))))

Note that the padded ASN.1 will be of the following form:

01 | FF* | 00 | prefix | hash

where "|" is concatentation, "01", "FF", and "00" are fixed octets of
the corresponding hexadecimal value, "hash" is the SHA1 digest of the
data, and "prefix" is the ASN.1 BER SHA1 algorithm designator prefix
required in PKCS1 [RFC2437], that is,

hex 30 21 30 09 06 05 2B 0E 03 02 1A 05 00 04 14

This prefix is included to make it easier to use standard
cryptographic libraries. The FF octet MUST be repeated the maximum
number of times such that the value of the quantity being CRYPTed is
one octet shorter than the RSA modulus.

The resulting base64 [MIME] string is the value of the child text
node of the SignatureValue element, e.g.

<SignatureValue>IWijxQjUrcXBYoCei4QxjWo9Kg8D3p9tlWoT4
t0/gyTE96639In0FZFY2/rvP+/bMJ01EArmKZsR5VW3rwoPxw=
</SignatureValue>

RSA key values have two fields Modulus and Exponent

<RSAKeyValue>

<Modulus>xA7SEU+e0yQH5rm9kbCDN9o3aPIo7HbP7tX6WOocLZAtNfyxSZDU16ksL6W

jubafOqNEpcwR3RdFsT7bCqnXPBe5ELh5u4VEy19MzxkXRgrMvavzyBpVRgBUwUlV
5foK5hhmbktQhyNdy/6LpQRhDUDsTvK+g9Ucj47es9AQJ3U=
</Modulus>
<Exponent>AQAB</Exponent>
</RSAKeyValue>

Schema:

<element name="RSAKeyValue">
<complexType>
<sequence>
<element name="Modulus" type="ds:CryptoBinary"/>
<element name="Exponent" type="ds:CryptoBinary"/>
</sequence>
</complexType>
</element>
DTD:

<!ELEMENT RSAKeyValue (Modulus, Exponent) >
<!ELEMENT Modulus (#PCDATA) >
<!ELEMENT Exponent (#PCDATA) >

6.5 Canonicalization Algorithms

If canonicalization is performed over octets, the canonicalization
algorithms take two implicit parameter: the content and its charset.
The charset is derived according to the rules of the transport
protocols and media types (e.g., RFC2376 [XML-MT] defines the media
types for XML). This information is necessary to correctly sign and
verify documents and often requires careful server side
configuration.

Various canonicalization algorithms require conversion to [UTF-8].The
two algorithms below understand at least [UTF-8] and [UTF-16] as
input encodings. We RECOMMEND that externally specified algorithms
do the same. Knowledge of other encodings is OPTIONAL.

Various canonicalization algorithms transcode from a non-Unicode
encoding to Unicode. The two algorithms below perform text
normalization during transcoding [NFC]. We RECOMMEND that externally

specified canonicalization algorithms do the same. (Note, there can
be ambiguities in converting existing charsets to Unicode, for an
example see the XML Japanese Profile [XML-Japanese] NOTE.)

6.5.1 Minimal Canonicalization

Identifier:
http://www.w3.org/2000/09/xmldsig#minimal

An example of a minimal canonicalization element is:
<CanonicalizationMethod Algorithm="&dsig;minimal"/>

The minimal canonicalization algorithm:

* converts the character encoding to UTF-8 (without any byte
order mark (BOM)). If an encoding is given in the XML
declaration, it must be removed. Implementations MUST
understand at least [UTF-8] and [UTF-16] as input encodings.
Non-Unicode to Unicode transcoding MUST perform text
normalization [NFC].
* normalizes line endings as provided by [XML]. (See XML and
Canonicalization and Syntactical Considerations (section 7).)

This algorithm requires as input the octet stream of the resource to
be processed; the algorithm outputs an octet stream. When used to
canonicalize SignedInfo the algorithm MUST be provided with the
octets that represent the well-formed SignedInfo element (and its
children and content) as described in The CanonicalizationMethod
Element (section 4.3.1).

If the signature application has a node set, then the signature
application must convert it into octets as described in The Reference
Processing Model (section 4.3.3.2). However, Minimal
Canonicalization is NOT RECOMMENDED for processing XPath node-sets,
the results of same-document URI references, and the output of other
types of XML based transforms. It is only RECOMMENDED for simple
character normalization of well formed XML that has no namespace or
external entity complications.

6.5.2 Canonical XML

Identifier for REQUIRED Canonical XML (omits comments):
http://www.w3.org/TR/2000/CR-xml-c14n-20001026

Identifier for Canonical XML with Comments:
http://www.w3.org/TR/2000/CR-xml-c14n-20001026#WithComments

An example of an XML canonicalization element is:

<CanonicalizationMethod Algorithm="http://www.w3.org/TR/2000/CR-xml-
c14n-20001026"/>

The normative specification of Canonical XML is [XML-C14N]. The
algorithm is capable of taking as input either an octet stream or an
XPath node-set (or sufficiently functional alternative). The
algorithm produces an octet stream as output. Canonical XML is
easily parameterized (via an additional URI) to omit or retain
comments.

6.6 Transform Algorithms

A Transform algorithm has a single implicit parameters: an octet
stream from the Reference or the output of an earlier Transform.

Application developers are strongly encouraged to support all
transforms listed in this section as RECOMMENDED unless the
application environment has resource constraints that would make such
support impractical. Compliance with this recommendation will
maximize application interoperability and libraries should be
available to enable support of these transforms in applications
without extensive development.

6.6.1 Canonicalization

Any canonicalization algorithm that can be used for
CanonicalizationMethod (such as those in Canonicalization Algorithms
(section 6.5)) can be used as a Transform.

6.6.2 Base64

Identifiers:
http://www.w3.org/2000/09/xmldsig#base64

The normative specification for base 64 decoding transforms is
[MIME]. The base64 Transform element has no content. The input is
decoded by the algorithms. This transform is useful if an
application needs to sign the raw data associated with the encoded
content of an element.

This transform requires an octet stream for input. If an XPath
node-set (or sufficiently functional alternative) is given as input,
then it is converted to an octet stream by performing operations
logically equivalent to 1) applying an XPath transform with
expression self::text(), then 2) taking the string-value of the
node-set. Thus, if an XML element is identified by a barename
XPointer in the Reference URI, and its content consists solely of
base64 encoded character data, then this transform automatically

strips away the start and end tags of the identified element and any
of its descendant elements as well as any descendant comments and
processing instructions. The output of this transform is an octet
stream.

6.6.3 XPath Filtering

Identifier:
http://www.w3.org/TR/1999/REC-xpath-19991116

The normative specification for XPath expression evaluation is
[XPath]. The XPath expression to be evaluated appears as the
character content of a transform parameter child element named XPath.

The input required by this transform is an XPath node-set. Note that
if the actual input is an XPath node-set resulting from a null URI or
barename XPointer dereference, then comment nodes will have been
omitted. If the actual input is an octet stream, then the
application MUST convert the octet stream to an XPath node-set
suitable for use by Canonical XML with Comments (a subsequent
application of the REQUIRED Canonical XML algorithm would strip away
these comments). In other words, the input node-set should be
equivalent to the one that would be created by the following process:

1. Initialize an XPath evaluation context by setting the initial node
equal to the input XML document's root node, and set the context
position and size to 1.
2. Evaluate the XPath expression (//. | //@* | //namespace::*)

The evaluation of this expression includes all of the document's
nodes (including comments) in the node-set representing the octet
stream.

The transform output is also an XPath node-set. The XPath expression
appearing in the XPath parameter is evaluated once for each node in
the input node-set. The result is converted to a boolean. If the
boolean is true, then the node is included in the output node-set.
If the boolean is false, then the node is omitted from the output
node-set.

Note: Even if the input node-set has had comments removed, the
comment nodes still exist in the underlying parse tree and can
separate text nodes. For example, the markup <e>Hello,  world!</e> contains two text nodes. Therefore, the expression
self::text()[string()="Hello, world!"] would fail. Should this
problem arise in the application, it can be solved by either
canonicalizing the document before the XPath transform to physically

remove the comments or by matching the node based on the parent
element's string value (e.g., by using the expression
self::text()[string(parent::e)="Hello, world!"]).

The primary purpose of this transform is to ensure that only

协议分析网

搜索

RFC3075 - XML-Signature Syntax and Processing(2)