RFC3275 - (Extensible Markup Language) XML-Signature Syntax(2)

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 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.

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 node-sets" 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 an octet stream and the next transform
requires a node-set, the signature application MUST attempt to
parse the octets yielding the required node-set via [XML]
well-formed processing.
* If the data object is a node-set and the next transform
requires octets, the signature application MUST attempt to
convert the node-set to an octet stream using Canonical XML
[XML-C14N].

Users may specify alternative transforms that override 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 transform that requires XML
parsing is applied. (See Transforms (section 4.3.3.1).)

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 any canonicalization that preserves comments.
(Otherwise URI="#foo" will automatically remove comments before the
canonicalization 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 an 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 transform rather than a URI fragment (barename XPointer
resolution in external resources is not REQUIRED in this
specification).
URI=""
Identifies the node-set (minus any comment nodes) of the XML
resource containing the signature
URI="#chapter1"
Identifies a node-set containing the element with ID attribute
value 'chapter1' of the XML resource containing the signature.
XML Signature (and its applications) modify this node-set 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 [XML-C14N]. 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. It's necessary because when [XML-C14N] is
passed a node-set, it processes the node-set as is: with or without
comments. Only when it's called with an octet stream does it invoke
its own XPath expressions (default or without comments). Therefore
to retain the default behavior of stripping comments when passed a
node-set, they are removed in the last step if the URI is not a full
XPointer. 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 Transforms 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) define the list of standard transformations.

Schema Definition:

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

<element name="Transform" type="ds:TransformType"/>
<complexType name="TransformType" mixed="true">
<choice minOccurs="0" maxOccurs="unbounded">
<any namespace="##other" processContents="lax"/>

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

DTD:

<!ELEMENT Transforms (Transform+)>

<!ELEMENT Transform (#PCDATA|XPath %Transform.ANY;)* >
<!ATTLIST Transform
Algorithm CDATA #REQUIRED >

<!ELEMENT XPath (#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 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" type="ds:DigestMethodType"/>
<complexType name="DigestMethodType" mixed="true">
<sequence>
<any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</sequence>
<attribute name="Algorithm" type="anyURI" use="required"/>
</complexType>

DTD:

<!ELEMENT DigestMethod (#PCDATA %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:DigestValueType"/>
<simpleType name="DigestValueType">
<restriction base="base64Binary"/>
</simpleType>

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
extend those types or all together replace them with their own key
identification and exchange semantics using the XML namespace
facility. [XML-ns] However, questions of trust of such key
information (e.g., its authenticity or strength) are out of scope of
this specification and left to the application.

If KeyInfo is omitted, the recipient is expected to be able to
identify the key based on application context. 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 schema/DTD specifications of many of KeyInfo's children (e.g.,
PGPData, SPKIData, X509Data) permit their content to be
extended/complemented with elements from another namespace. This may
be done only if it is safe to ignore these extension elements while
claiming support for the types defined in this specification.
Otherwise, external elements, including alternative structures to
those defined by this specification, MUST be a child of KeyInfo. For
example, should a complete XML-PGP standard be defined, its root
element MUST be a child of KeyInfo. (Of course, new structures from
external namespaces can incorporate elements from the &dsig;
namespace via features of the type definition language. For
instance, they can create a DTD that mixes their own and dsig
qualified elements, or a schema that permits, includes, imports, or
derives new types based on &dsig; elements.)

The following list summarizes the KeyInfo types that are allocated to
an identifier in the &dsig; namespace; these can be used within the
RetrievalMethod Type attribute to describe a remote KeyInfo
structure.

* http://www.w3.org/2000/09/xmldsig#DSAKeyValue
* http://www.w3.org/2000/09/xmldsig#RSAKeyValue
* 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 an XML structure,
we specify one additional type to indicate a binary (ASN.1 DER) X.509
Certificate.

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

Schema Definition:

<element name="KeyInfo" type="ds:KeyInfoType"/>
<complexType name="KeyInfoType" mixed="true">
<choice maxOccurs="unbounded">
<element ref="ds:KeyName"/>
<element ref="ds:KeyValue"/>
<element ref="ds:RetrievalMethod"/>
<element ref="ds:X509Data"/>
<element ref="ds:PGPData"/>
<element ref="ds:SPKIData"/>
<element ref="ds:MgmtData"/>
<any processContents="lax" namespace="##other"/>

</choice>
<attribute name="Id" type="ID" use="optional"/>
</complexType>

DTD:

<!ELEMENT KeyInfo (#PCDATA|KeyName|KeyValue|RetrievalMethod|
X509Data|PGPData|SPKIData|MgmtData %KeyInfo.ANY;)* >
<!ATTLIST KeyInfo
Id ID #IMPLIED >

4.4.1 The KeyName Element

The KeyName element contains a string value (in which white space is
significant) 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:

<element name="KeyName" type="string"/>

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). The KeyValue element may include
externally defined public key values represented as PCDATA or element
types from an external namespace.

Schema Definition:

<element name="KeyValue" type="ds:KeyValueType"/>
<complexType name="KeyValueType" mixed="true">
<choice>
<element ref="ds:DSAKeyValue"/>
<element ref="ds:RSAKeyValue"/>
<any namespace="##other" processContents="lax"/>
</choice>
</complexType>

DTD:

<!ELEMENT KeyValue (#PCDATA|DSAKeyValue|RSAKeyValue
%KeyValue.ANY;)* >

4.4.2.1 The DSAKeyValue Element

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

DSA keys and the DSA signature algorithm are specified in [DSS]. DSA
public key values can have the following fields:

P
a prime modulus meeting the [DSS] requirements
Q
an integer in the range 2**159 < Q < 2**160 which is a prime
divisor of P-1
G
an integer with certain properties with respect to P and Q
Y
G**X mod P (where X is part of the private key and not made
public)
J
(P - 1) / Q
seed
a DSA prime generation seed
pgenCounter
a DSA prime generation counter

Parameter J is available for inclusion solely for efficiency as it is
calculatable from P and Q. Parameters seed and pgenCounter are used
in the DSA prime number generation algorithm specified in [DSS]. As
such, they are optional, but must either both be present or both be
absent. This prime generation algorithm is designed to provide
assurance that a weak prime is not being used and it yields a P and Q
value. Parameters P, Q, and G can be public and common to a group of
users. They might be known from application context. As such, they
are optional but P and Q must either both appear or both be absent.
If all of P, Q, seed, and pgenCounter are present, implementations
are not required to check if they are consistent and are free to use
either P and Q or seed and pgenCounter. All parameters are encoded
as base64 [MIME] values.

Arbitrary-length integers (e.g., "bignums" such as RSA moduli) are
represented in XML as octet strings as defined by the ds:CryptoBinary
type.

Schema Definition:

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

DTD Definition:

<!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) >

4.4.2.2 The RSAKeyValue Element

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

RSA key values have two fields: Modulus and Exponent.

<RSAKeyValue>
<Modulus>
xA7SEU+e0yQH5rm9kbCDN9o3aPIo7HbP7tX6WOocLZAtNfyxSZDU16ksL6W
jubafOqNEpcwR3RdFsT7bCqnXPBe5ELh5u4VEy19MzxkXRgrMvavzyBpVRg
BUwUlV5foK5hhmbktQhyNdy/6LpQRhDUDsTvK+g9Ucj47es9AQJ3U=
</Modulus>
<Exponent>AQAB</Exponent>
</RSAKeyValue>

Arbitrary-length integers (e.g., "bignums" such as RSA moduli) are
represented in XML as octet strings as defined by the ds:CryptoBinary
type.

Schema Definition:

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

DTD Definition:

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

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.

Type is an optional identifier for the type of data to be retrieved.
The result of dereferencing a RetrievalMethod Reference for all
KeyInfo types defined by this specification (section 4.4) with a
corresponding XML structure is an XML element or document with that
element as the root. The rawX509Certificate KeyInfo (for which there
is no XML structure) returns a binary X509 certificate.

Schema Definition:

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

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 a
revocation list). The content of X509Data is:

1. At least one element, from the following set of element types; any
of these may appear together or more than once if (if and only if)
each instance describes or is related to the same certificate:
2.
o The X509IssuerSerial element, which contains an X.509 issuer
distinguished name/serial number pair that SHOULD be compliant
with RFC2253 [LDAP-DN],
o The X509SubjectName element, which contains an X.509 subject
distinguished name that SHOULD be compliant with RFC2253
[LDAP-DN],
o The X509SKI element, which contains the base64 encoded plain
(i.e., non-DER-encoded) value of a X509 V.3
SubjectKeyIdentifier extension.
o The X509Certificate element, which contains a base64-encoded
[X509v3] certificate, and
o Elements from an external namespace which
accompanies/complements any of the elements above.
o The X509CRL element, which contains a base64-encoded
certificate revocation list (CRL) [X509v3].

Any X509IssuerSerial, X509SKI, and X509SubjectName elements that
appear MUST refer to the certificate or certificates containing the
validation key. All such elements that refer to a particular
individual certificate MUST be grouped inside a single X509Data
element and if the certificate to which they refer appears, it MUST
also be in that X509Data element.

Any X509IssuerSerial, X509SKI, and X509SubjectName elements that
relate to the same key but different certificates MUST be grouped
within a single KeyInfo but MAY occur in multiple X509Data elements.

All certificates appearing in an X509Data element MUST relate to the
validation key by either containing it or being part of a
certification chain that terminates in a certificate containing the
validation key.

No ordering is implied by the above constraints. The comments in the
following instance demonstrate these constraints:

<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>
<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 and CRLs 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.

Also, strings in DNames (X509IssuerSerial,X509SubjectName, and
KeyNameif appropriate) should be encoded as follows:

* Consider the string as consisting of Unicode characters.
* Escape occurrences of the following special characters by
prefixing it with the "\" character: a "#" character occurring
at the beginning of the string or one of the characters ",",
"+", """, "\", "<", ">" or ";"
* Escape all occurrences of ASCII control characters (Unicode
range \x00 - \x 1f) by replacing them with "\" followed by a
two digit hex number showing its Unicode number.
* Escape any trailing white space by replacing "\ " with "\20".
* Since a XML document logically consists of characters, not
octets, the resulting Unicode string is finally encoded
according to the character encoding used for producing the
physical representation of the XML document.

Schema Definition:

<element name="X509Data" type="ds:X509DataType"/>
<complexType name="X509DataType">
<sequence maxOccurs="unbounded">
<choice>
<element name="X509IssuerSerial"
type="ds:X509IssuerSerialType"/>
<element name="X509SKI" type="base64Binary"/>
<element name="X509SubjectName" type="string"/>
<element name="X509Certificate" type="base64Binary"/>
<element name="X509CRL" type="base64Binary"/>
<any namespace="##other" processContents="lax"/>
</choice>
</sequence>
</complexType>
<complexType name="X509IssuerSerialType">
<sequence>
<element name="X509IssuerName" type="string"/>
<element name="X509SerialNumber" type="integer"/>
</sequence>
</complexType>

DTD:

<!ELEMENT X509Data ((X509IssuerSerial | X509SKI | X509SubjectName
| X509Certificate | X509CRL)+ %X509.ANY;)>
<!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 base64Binary sequence 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]. These children element types can be
complemented/extended by siblings from an external namespace within
PGPData, or PGPData can be replaced all together with an alternative
PGP XML structure as a child of KeyInfo. PGPData must contain one
PGPKeyID and/or one PGPKeyPacket and 0 or more elements from an
external namespace.

Schema Definition:

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

DTD:

<!ELEMENT PGPData ((PGPKeyID, PGPKeyPacket?) | (PGPKeyPacket)
%PGPData.ANY;) >
<!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.
SPKISexp is the base64 encoding of a SPKI canonical S-expression.
SPKIData must have at least one SPKISexp; SPKISexp can be
complemented/extended by siblings from an external namespace within
SPKIData, or SPKIData can be entirely replaced with an alternative
SPKI XML structure as a child of KeyInfo.

Schema Definition:

<element name="SPKIData" type="ds:SPKIDataType"/>
<complexType name="SPKIDataType">
<sequence maxOccurs="unbounded">
<element name="SPKISexp" type="base64Binary"/>
<any namespace="##other" processContents="lax" minOccurs="0"/>
</sequence>
</complexType>

DTD:

<!ELEMENT SPKIData (SPKISexp %SPKIData.ANY;) >
<!ELEMENT SPKISexp (#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. Use of this element is NOT
RECOMMENDED. It provides a syntactic hook where in-band key
distribution or agreement data can be placed. However, superior
interoperable child elements of KeyInfo for the transmission of
encrypted keys and for key agreement are being specified by the W3C
XML Encryption Working Group and they should be used instead of
MgmtData.

Schema Definition:

<element name="MgmtData" type="string"/>

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 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).

The MimeType attribute is an optional attribute which describes the
data within the Object (independent of its encoding). This is a
string with values defined by [MIME]. For example, if the Object
contains base64 encoded PNG, the Encoding may be specified as
'base64' and the MimeType as 'image/png'. This attribute is purely
advisory; no validation of the MimeType information is required by
this specification. Applications which require normative type and
encoding information for signature validation should specify
Transforms with well defined resulting types and/or encodings.

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.

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" type="ds:ObjectType"/>
<complexType name="ObjectType" mixed="true">
<sequence minOccurs="0" 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="anyURI" use="optional"/>
</complexType>

DTD:

<!ELEMENT Object (#PCDATA|Signature|SignatureProperties|Manifest
%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" type="ds:ManifestType"/>
<complexType name="ManifestType">
<sequence>
<element ref="ds:Reference" maxOccurs="unbounded"/>
</sequence>
<attribute name="Id" type="ID" use="optional"/>
</complexType>

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"
type="ds:SignaturePropertiesType"/>
<complexType name="SignaturePropertiesType">
<sequence>
<element ref="ds:SignatureProperty" maxOccurs="unbounded"/>
</sequence>
<attribute name="Id" type="ID" use="optional"/>
</complexType>

<element name="SignatureProperty"
type="ds:SignaturePropertyType"/>
<complexType name="SignaturePropertyType" mixed="true">
<choice maxOccurs="unbounded">
<any namespace="##other" processContents="lax"/>

</choice>
<attribute name="Target" type="anyURI" use="required"/>
<attribute name="Id" type="ID" use="optional"/>
</complexType>

DTD:

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

<!ELEMENT SignatureProperty (#PCDATA %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 identified 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.

Digest
1. Required SHA1
http://www.w3.org/2000/09/xmldsig#sha1
Encoding
1. Required base64
http://www.w3.org/2000/09/xmldsig#base64
MAC
1. Required HMAC-SHA1
http://www.w3.org/2000/09/xmldsig#hmac-sha1
Signature
1. Required DSAwithSHA1 (DSS)
http://www.w3.org/2000/09/xmldsig#dsa-sha1
2. Recommended RSAwithSHA1
http://www.w3.org/2000/09/xmldsig#rsa-sha1
Canonicalization
1. Required Canonical XML (omits comments)
http://www.w3.org/TR/2001/REC-xml-c14n-20010315
2. Recommended Canonical XML with Comments
http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments
Transform
1. Optional XSLT
http://www.w3.org/TR/1999/REC-xslt-19991116
2. Recommended XPath
http://www.w3.org/TR/1999/REC-xpath-19991116
3. Required Enveloped Signature*
http://www.w3.org/2000/09/xmldsig#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 cryptanalysis 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="http://www.w3.org/2000/09/xmldsig#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

协议分析网

搜索

RFC3275 - (Extensible Markup Language) XML-Signature Syntax(2)