4.4 The SignedInfo Element
The structure of SignedInfo includes the canonicalization
algorithm, a signature algorithm, and one or more references. The
SignedInfo element may contain an optional ID attribute that will allow
it to be referenced by other signatures and objects.
SignedInfo does not include explicit signature or digest
properties (such as calculation time, cryptographic device serial number,
etc.). If an application needs to associate properties with the signature or
digest, it may include such information in a SignatureProperties
element within an Object element.
Schema Definition:
<element name="SignedInfo" type="ds:SignedInfoType"/>
<complexType name="SignedInfoType">
<sequence>
<element ref="ds:CanonicalizationMethod"/>
<element ref="ds:SignatureMethod"/>
<element ref="ds:Reference" maxOccurs="unbounded"/>
</sequence>
<attribute name="Id" type="ID" use="optional"/>
</complexType>
4.4.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 canonicalization algorithms.
Alternatives to the required canonicalization algorithms (section 6.5), such as
Canonical XML with Comments (section
6.5.1) or a minimal canonicalization (such as CRLF and charset
normalization)
,
may be explicitly specified but are not required. Consequently, their use may
not interoperate with other applications that do not 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 non-XML aware canonicalization algorithms are not
properly constrained (see section 8.1.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
algorithms which process XML as nodes or characters:
- XML based canonicalization implementations 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.
- Text based canonicalization algorithms (such as CRLF and charset
normalization) should be provided with the UTF-8 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 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. Use of text based canonicalization of
SignedInfo is not recommended.
We recommend applications that implement a text-based instead of XML-based
canonicalization -- such as resource constrained apps -- generate
canonicalized XML as their output serialization so as to mitigate
interoperability and security concerns. For instance, such an implementation
should (at least) generate
standalone XML
instances [XML10].
Note: The signature
application must exercise great care in accepting and executing an arbitrary
CanonicalizationMethod. For example, the canonicalization method could
rewrite the URIs of the References being validated. Or, the
method could massively transform SignedInfo so that validation
would always succeed (i.e., converting it to a trivial signature with a known
key over trivial data). Since
CanonicalizationMethod is inside
SignedInfo, in the resulting canonical form it could erase itself
from SignedInfo or modify the
SignedInfo element so that it appears that a different
canonicalization function was used! Thus a
Signature which appears to authenticate the desired data with the
desired key, DigestMethod, and
SignatureMethod, can be meaningless if a capricious
CanonicalizationMethod is used.
Schema Definition:
<element name="CanonicalizationMethod" type="ds:CanonicalizationMethodType"/>
<complexType name="CanonicalizationMethodType" mixed="true">
<sequence>
<any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
<!-- (0,unbounded) elements from (1,1) namespace -->
</sequence>
<attribute name="Algorithm" type="anyURI" use="required"/>
</complexType>
4.4.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" type="ds:SignatureMethodType"/>
<complexType name="SignatureMethodType" mixed="true">
<sequence>
<element name="HMACOutputLength" minOccurs="0" type="ds:HMACOutputLengthType"/>
<any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
<!-- (0,unbounded) elements from (1,1) external namespace -->
</sequence>
<attribute name="Algorithm" type="anyURI" use="required"/>
</complexType>
The ds:HMACOutputLength parameter is used for HMAC [HMAC] algorithms. The
parameter specifies a truncation length in bits. If this parameter is trusted without further
verification, then this can lead to a security bypass
[CVE-2009-0217].
Signatures must be deemed invalid if the truncation length is below
the larger of (a) half the underlying hash algorithm's output length,
and (b) 80 bits.
Note that some implementations are known to not
accept truncation lengths that are lower than the underlying hash algorithm's output length.
4.4.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" type="ds:ReferenceType"/>
<complexType name="ReferenceType">
<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="anyURI" use="optional"/>
<attribute name="Type" type="anyURI" use="optional"/>
</complexType>
4.4.3.1 The URI Attribute
The URI attribute identifies a data object using a
URI-Reference [URI].
The mapping from this attribute's value to a URI reference must be
performed as specified in section 3.2.17 of
[XMLSCHEMA-2].
Additionally: Some existing implementations are known to verify the value of
the URI attribute against the grammar in [URI].
It is therefore safest to perform any necessary escaping while generating the
URI attribute.
We RECOMMEND XML Signature applications be able to dereference URIs in the
HTTP scheme. Dereferencing a URI in the HTTP scheme must comply with the Status Code Definitions of [HTTP11] (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 (section
3.2.1) for 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 after all ds:Reference
transforms have been applied. 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 results in the digesting of 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.4.3.2 The Reference Processing Model
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 [XML10]
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.
Note: The Reference Generation Model (section 3.1.1) includes further
restrictions on the reliance upon defined default transformations when
applications generate signatures.
In this specification, a 'same-document' reference is defined as a
URI-Reference that consists of a hash sign ('#') followed by a fragment or
alternatively consists of an empty URI [URI].
Unless the URI-Reference is such a 'same-document' reference , 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.4.3.4).)
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 [RFC2045]. 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 in this case that the
URI attribute not include fragment identifiers and that
such processing be specified as an
additional XPath Transform
or XPath Filter 2 Transform [XMLDSIG-XPATH-FILTER2].
When a fragment is not preceded by a URI in the URI-Reference, XML
Signature applications must support the null URI and shortname XPointer [XPTR-FRAMEWORK]. 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 due to the processing defined in Same-Document URI-References (section 4.4.3.3).) All other support
for XPointers is optional, especially all support for shortname 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).
'#xpointer(/)' must be interpreted to identify the
root node [XPATH]
of the document that contains the URI attribute.
'#xpointer(id('ID'))' must be interpreted
to identify
the element node identified by '#element(ID)'
[XPTR-ELEMENT] when evaluated with
respect to the document that contains the
URI attribute.
The original edition of this specification [XMLDSIG-CORE]
referenced the XPointer
Candidate Recommendation [XPTR-XPOINTER-CR2001]
and some implementations support it optionally.
That Candidate Recommendation has been superseded by the
[XPTR-FRAMEWORK], [XPTR-XMLNS] and [XPTR-ELEMENT] Recommendations,
and -- at the time of this edition -- the
[XPTR-XPOINTER]
Working Draft. Therefore, the use of
the
xpointer() scheme [XPTR-XPOINTER] beyond the usage
discussed in this section is discouraged.
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 (shortname 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
descendants including namespaces and attributes -- but not comments.
4.4.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-FRAMEWORK]. When processing an XPointer, the application
must behave as if the XPointer was evaluated with respect to the XML document
containing the URI
attribute . The application must behave as if the result of XPointer
processing [XPTR-FRAMEWORK] were a node-set derived from the resultant
subresource as follows:
- include XPath nodes having full or partial content within the
subresource
- replace the root node with its children (if it is in the node-set)
- 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.
- if the URI has no fragment identifier or the fragment identifier is a
shortname 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 and shortname XPointers . It is
necessary because when [XML-C14N] or [XML-C14N11] is passed a
node-set, it processes the node-set as is:
with or without comments. Only when it is 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 scheme-based XPointer. To
retain comments while selecting an element by an identifier ID, use
the following scheme-based XPointer:
URI='#xpointer(id('ID'))'. To retain comments while
selecting the entire document, use the following scheme-based XPointer:
URI='#xpointer(/)'.
The interpretation of these XPointers is defined in The Reference Processing Model
(section 4.4.3.2).
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.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.1).)
As described in The Reference Processing Model (section 4.4.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 [RFC2045],
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" 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"/>
<!-- (1,1) elements from (0,unbounded) namespaces -->
<element name="XPath" type="string"/>
</choice>
<attribute name="Algorithm" type="anyURI" use="required"/>
</complexType>
4.4.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.4.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>
4.4.3.6 The DigestValue Element
DigestValue is an element that contains the encoded value of the digest.
The digest is always encoded using base64 [RFC2045].
Schema Definition:
<element name="DigestValue" type="ds:DigestValueType"/>
<simpleType name="DigestValueType">
<restriction base="base64Binary"/>
</simpleType>
4.5 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-NAMES].
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.5.2) and
should implement RetrievalMethod (section 4.5.3).
The schema specification 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 schema that permits, includes,
imports, or derives new types based on dsig: elements.)
The following list summarizes the KeyInfo types that are
allocated an identifier in the dsig:
namespace; these can be used within the
RetrievalMethod Type attribute to describe a remote
KeyInfo structure.
The following list summarizes the additional KeyInfo
types that are allocated an identifier in the dsig11:
namespace.
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.
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"/>
<!-- <element ref="dsig11:DEREncodedKeyValue"/> -->
<!-- DEREncodedKeyValue (XMLDsig 1.1) will use the any element -->
<any processContents="lax" namespace="##other"/>
<!-- (1,1) elements from (0,unbounded) namespaces -->
</choice>
<attribute name="Id" type="ID" use="optional"/>
</complexType>
4.5.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"/>
4.5.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), RSA (required) and ECDSA (required) public keys are defined in Signature Algorithms (section 6.4). The
KeyValue element may include externally defined public keys
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"/>
<!-- <element ref="dsig11:ECKeyValue"/> -->
<!-- ECC keys (XMLDsig 1.1) will use the any element -->
<any namespace="##other" processContents="lax"/>
</choice>
</complexType>
4.5.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
[FIPS-186-3]. DSA public
key values can have the following fields:
P- a prime modulus meeting the [FIPS-186-3] 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 [FIPS-186-3]. 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
[RFC2045]
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>
4.5.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
jubafOqNEpcwR3RdFsT7bCqnXPBe5ELh5u4VEy19MzxkXRgrMvavzyBpVRgBUwUlV
5foK5hhmbktQhyNdy/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>
4.5.2.3 The ECKeyValue Element
- Identifier
Type="http://www.w3.org/2009/xmldsig11#ECKeyValue"
(this can be used within a RetrievalMethod
or Reference element to identify the referent's type)
The ECPublicKey element is defined in the
http://www.w3.org/2009/xmldsig11# namespace.
EC public key values consists of two sub components: Domain parameters and
PublicKey.
<ECKeyValue xmlns="http://www.w3.org/2009/xmldsig11#">
<NamedCurve URI="urn:oid:1.2.840.10045.3.1.7" />
<PublicKey>
vWccUP6Jp3pcaMCGIcAh3YOev4gaa2ukOANC7Ufg
Cf8KDO7AtTOsGJK7/TA8IC3vZoCy9I5oPjRhyTBulBnj7Y
</PublicKey>
</ECKeyValue>
Note - A line break has been added to the PublicKey
content to preserve printed page width.
Domain parameters can be encoded explicitly using the ECParameters element
or by reference using the NamedCurve element. A named curve is specified
through the URN attribute. For named curves that are identified by
OIDs, such as those defined in [RFC3279][RFC4055],
and [SECG1], the OID should be encoded
according to [URN-OID]. Conformant
applications must support the NamedCurve element and the 256-bit prime field
curve as identified by the OID 1.2.840.10045.3.1.7.
The PublicKey element contains a Base64 encoding of a binary representation
of the x and y coordinates of the point. Its value is computed as
follows:
- Convert the elliptic curve point (x,y) to an octet string as specified
in Section 2.3.3 of [SECG1]. Support for
Elliptic-Curve-Point-to-Octet-String conversion without point
compression is
required.
- Base64 encode the octet string resulting from the
conversion in Step 1.
Schema Definition:
<!-- targetNamespace="http://www.w3.org/2009/xmldsig11#" -->
<element name="ECKeyValue" type="dsig11:ECKeyValueType"/>
<complexType name="ECKeyValueType">
<sequence>
<choice>
<element name="ECParameters" type="dsig11:ECParametersType"/>
<element name="NamedCurve" type="dsig11:NamedCurveType"/>
</choice>
<element name="PublicKey" type="dsig11:ECPointType"/>
</sequence>
<attribute name="Id" type="ID" use="optional"/>
</complexType>
<complexType name="NamedCurveType">
<attribute name="URI" type="anyURI" use="required"/>
</complexType>
<simpleType name="ECPointType">
<restriction base="ds:CryptoBinary"/>
</simpleType>
4.5.2.3.1 Explicit Curve Parameters
The ECParameters element consists of the following subelements. Note these
definitions are based on the those described in [RFC3279].
- The FieldID element identifies the finite field over which the elliptic
curve is defined. Additional details on the structures for defining prime
and characteristic two fields is provided below.
- The Curve element specifies the coefficients a and b of the elliptic
curve E. Each coefficient is first converted from a field element to an
octet string as specified in section 2.3.5 of [SECG1], then
the resultant octet string is encoded in
base64.
- The Base element specifies the base point P on the elliptic curve. The
base point is represented as a value of type ECPointType.
- The Order element specifies the order n of the base point and is encoded
as a positiveInteger.
- The Cofactor element is an optional element that specifies the integer h
= #E(Fq)/n. The cofactor is not required to support ECDSA, except in
parameter validation. The cofactor may be included to support parameter
validation for ECDSA keys. Parameter validation is not required by this
specification. The cofactor is required in ECDH public key parameters.
- The ValidationData element is an optional element that
specifies the hash algorithm used to generate the elliptic curve E
and the base point G verifiably at random. It also specifies the
seed that was used to generate the curve and the base point. When
verifiably random curves and base points are used, they shall be
generated as described in Section 3.1.3 of [SECG1].
Schema Definition:
<!-- targetNamespace="http://www.w3.org/2009/xmldsig11#" -->
<complexType name="ECParametersType">
<sequence>
<element name="FieldID" type="dsig11:FieldIDType"/>
<element name="Curve" type="dsig11:CurveType"/>
<element name="Base" type="dsig11:ECPointType"/>
<element name="Order" type="ds:CryptoBinary"/>
<element name="CoFactor" type="integer" minOccurs="0"/>
<element name="ValidationData" type="dsig11:ECValidationDataType" minOccurs="0"/>
</sequence>
</complexType>
<complexType name="FieldIDType">
<choice>
<element ref="dsig11:Prime"/>
<element ref="dsig11:TnB"/>
<element ref="dsig11:PnB"/>
<element ref="dsig11:GnB"/>
<any namespace="##other" processContents="lax"/>
</choice>
</complexType>
<complexType name="CurveType">
<sequence>
<element name="A" type="ds:CryptoBinary"/>
<element name="B" type="ds:CryptoBinary"/>
</sequence>
</complexType>
<complexType name="ECValidationDataType">
<sequence>
<element name="seed" type="ds:CryptoBinary"/>
</sequence>
<attribute name="hashAlgorithm" type="anyURI" use="required"/>
</complexType>
Prime fields are described by a single subelement P, which represents the
field size in bits. It is encoded as a positiveInteger.
Schema Definition:
<!-- targetNamespace="http://www.w3.org/2009/xmldsig11#" -->
<element name="Prime" type="dsig11:PrimeFieldParamsType"/>
<complexType name="PrimeFieldParamsType">
<sequence>
<element name="P" type="ds:CryptoBinary"/>
</sequence>
</complexType>
Structures are defined for three types of characteristic two fields:
gaussian normal basis, pentanomial basis and trinomial basis.
Schema Definition:
<!-- targetNamespace="http://www.w3.org/2009/xmldsig11#" -->
<element name="GnB" type="dsig11:CharTwoFieldParamsType"/>
<complexType name="CharTwoFieldParamsType">
<sequence>
<element name="M" type="positiveInteger"/>
</sequence>
</complexType>
<element name="TnB" type="dsig11:TnBFieldParamsType"/>
<complexType name="TnBFieldParamsType">
<complexContent>
<extension base="dsig11:CharTwoFieldParamsType">
<sequence>
<element name="K" type="positiveInteger"/>
</sequence>
</extension>
</complexContent>
</complexType>
<element name="PnB" type="dsig11:PnBFieldParamsType"/>
<complexType name="PnBFieldParamsType">
<complexContent>
<extension base="dsig11:CharTwoFieldParamsType">
<sequence>
<element name="K1" type="positiveInteger"/>
<element name="K2" type="positiveInteger"/>
<element name="K3" type="positiveInteger"/>
</sequence>
</extension>
</complexContent>
</complexType>
4.5.2.3.2 Compatibility with RFC 4050
Implementations that need to support the [RFC4050]
format for ECDSA keys can avoid known interoperability problems with that
specification by adhering to the following profile:
- Avoid validating the
ECDSAKeyValue element against the [RFC4050]
schema. XML schema validators may not support integer types with decimal data
exceeding 18 decimal digits.
[XMLSCHEMA-1][XMLSCHEMA-2].
- Support only the
NamedCurve element.
- Support the 256-bit prime field curve, as identified by the URN
urn:oid:1.2.840.10045.3.1.7.
The following is an example of a ECDSAKeyValue element that meets the
profile described in this section.
<ECDSAKeyValue xmlns="http://www.w3.org/2001/04/xmldsig-more#">
<DomainParameters>
<NamedCurve URN="urn:oid:1.2.840.10045.3.1.7" />
</DomainParameters>
<PublicKey>
<X Value="5851106065380174439324917904648283332
0204931884267326155134056258624064349885">
<Y Value="1024033521368277752409102672177795083
59028642524881540878079119895764161434936">
</PublicKey>
</ECDSAKeyValue>
Note - A line break has been added to the X
and Y Value attribute values to preserve
printed page width.
4.5.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.4.3.1) and
The Reference Processing
Model (section 4.4.3.2) except that there are
no DigestMethod
or DigestValue
child elements and presence of the URI attribute is
mandatory.
Type is an optional identifier for the type of data retrieved
after all transforms have been applied. The result of dereferencing a
RetrievalMethod Reference for all KeyInfo types defined by this
specification (section 4.5) 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.
Note that when referencing one of the
defined KeyInfo types within the same document, or some remote documents, at
least one Transform is required to turn an ID-based
reference to a KeyInfo
element into a child element located inside it. This is due to the lack of
an XML ID attribute on the defined KeyInfo types.
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>
Note: The schema for the URI
attribute of RetrievalMethod erroneously omitted the attribute:
use="required". However, this error only results in a
more lax schema
which permits all valid RetrievalMethod
elements. Because the existing schema
is embedded in many applications, which may include the schema in their
signatures, the schema has not been corrected to be more restrictive.
4.5.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:
- At least one element, from the following set of element types; any of
these may appear together or more than once iff (if and only if) each
instance describes or is related to the same certificate:
-
- The
X509IssuerSerial element, which contains an X.509
issuer distinguished name/serial number pair. The distinguished name
should be represented as a string that complies with section 3 of
RFC4514 [LDAP-DN], to be generated according to the
Distinguished Name Encoding Rules
section below,
- The
X509SubjectName element, which contains an X.509
subject distinguished name that should be represented as a string that
complies with section 3 of RFC4514 [LDAP-DN], to be generated according to the
Distinguished Name Encoding Rules
section below,
- The
X509SKI element, which contains the base64 encoded
plain (i.e. non-DER-encoded) value of a X509 V.3 SubjectKeyIdentifier
extension,
- The
X509Certificate element, which contains a
base64-encoded [X509V3] certificate, and
- Elements from an external namespace which accompanies/complements
any of the elements above.
- The
X509CRL element, which contains a base64-encoded
certificate revocation list (CRL) [X509V3].
- The
dsig11:OCSPResponse element contains a base64-encoded OCSP response in
DER encoding. [OCSP].
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> <!-- two pointers to certificate-A -->
<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><!-- single pointer to certificate-B -->
<X509SubjectName>Subject of Certificate B</X509SubjectName>
</X509Data>
<X509Data> <!-- certificate chain -->
<!--Signer cert, issuer CN=arbolCA,OU=FVT,O=IBM,C=US, serial 4-->
<X509Certificate>MIICXTCCA..</X509Certificate>
<!-- Intermediate cert subject CN=arbolCA,OU=FVT,O=IBM,C=US
issuer CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US -->
<X509Certificate>MIICPzCCA...</X509Certificate>
<!-- Root cert subject CN=tootiseCA,OU=FVT,O=Bridgepoint,C=US -->
<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.
While in principle many certificate encodings are possible, it is recommended
that certificates appearing in an
X509Certificate element be limited to an encoding of BER or its DER
subset, allowing that within the certificate other content may be present. The
use of other encodings may lead to interoperability issues. In any case, XML
Signature implementations should not alter or re-encode certificates, as doing
so could invalidate their signatures.
Deployments that expect to make use of
the X509IssuerSerial element should
be aware that many Certificate Authorities issue certificates with large,
random serial numbers. Such deployments should avoid schema-validating the
X509IssuerSerial element as XML Schema validators may not
support integer types
with decimal data exceeding 18 decimal digits [XML-schema].
4.5.4.1 Distinguished Name Encoding Rules
To encode a distinguished name (X509IssuerSerial,X509SubjectName,
and
KeyName if appropriate), the encoding rules in section 2 of RFC
4514 [LDAP-DN] should be applied, except that the character escaping
rules in section 2.4 of RFC 4514 [LDAP-DN] may be augmented as follows:
- Escape all occurrences of ASCII control characters (Unicode range \x00 -
\x1f) by replacing them with "\" followed by a two digit hex number showing
its Unicode number.
- Escape any trailing space characters (Unicode \x20) by replacing them
with "\20", instead of using the escape sequence "\ ".
Since an 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"/>
<!-- <element ref="dsig11:OCSPResponse"/> -->
<!-- OCSPResponse elements (XMLDsig 1.1) will use the any element -->
<any namespace="##other" processContents="lax"/>
</choice>
</sequence>
</complexType>
<complexType name="X509IssuerSerialType">
<sequence>
<element name="X509IssuerName" type="string"/>
<element name="X509SerialNumber" type="integer"/>
</sequence>
</complexType>
<!-- Note, this schema permits X509Data to be empty; this is
precluded by the text in KeyInfo Element (section 4.5) which states
that at least one element from the dsig namespace should be present
in the PGP, SPKI, and X509 structures. This is easily expressed for
the other key types, but not for X509Data because of its rich
structure. -->
<!-- targetNameSpace="http://www.w3.org/2009/xmldsig11#" -->
<element name="OCSPResponse" type="base64Binary" />
4.5.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>
4.5.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>
4.5.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. However, use of this
element is
not recommended and
should not be used. Section
4.5.8
describes new
KeyInfo types for conveying key information.
Schema Definition:
<element name="MgmtData" type="string"/>
4.5.8 XML Encryption EncryptedKey
and Agreement Elements
The
<xenc:EncryptedKey>
and
<xenc:Agreement> elements defined in
[
XMLENC-CORE1] as children of
ds:KeyInfo can be used
to convey in-band
key agreement information, or encrypted key material.
4.5.9 The DEREncodedKeyValue Element
- Identifier
Type="http://www.w3.org/2009/xmldsig11#DEREncodedKeyValue"
(this can be used within a RetrievalMethod
or Reference element to identify the referent's type)
The public key algorithm and value are DER-encoded in accordance with the
value that would be used in the Subject Public Key Info field of an X.509
certificate, per section 4.1.2.7 of [RFC5280].
The DER-encoded value is then base64-encoded.
For the key value types supported in this specification, refer to the
following for normative references on the format of Subject Public Key Info
and the relevant OID values that identify the key/algorithm type:
- RSA
- See section 2.3.1 of [RFC3279]
- DSA
- See section 2.3.2 of [RFC3279]
- EC
- See section 2 of [RFC5480]
Specifications that define additional key types should provide such
a normative reference for their own key types where possible.
Schema Definition:
<!-- targetNamespace="http://www.w3.org/2009/xmldsig11#" -->
<element name="DEREncodedKeyValue" type="dsig11:DEREncodedKeyValueType"/>
<complexType name="DEREncodedKeyValueType">
<simpleContent>
<extension base="base64Binary">
<attribute name="Id" type="ID" use="optional"/>
</extension>
</simpleContent>
</complexType>
Historical note: The DEREncodedKeyValue element was added
to XML Signature 1.1 in order to support certain interoperability
scenarios where at least one of signer and/or verifier are not able to
serialize keys in the XML formats described in Section 4.5.2
above. The KeyValue element is to be used for
"bare" XML key
representations (not XML wrappings around other binary encodings like
ASN.1 DER); for this reason the DEREncodedKeyValue
element is not a
child of KeyValue.
The DEREncodedKeyValue element is also not a child of the
X509Data element, as the keys represented
by DEREncodedKeyValue may
not have X.509 certificates associated with them (a requirement for
X509Data).
4.6 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 [RFC2045].
For example, if the Object contains base64 encoded
PNG, the
Encoding may be specified as 'http://www.w3.org/2000/09/xmldsig#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>