Copyright
©
2010
©
2011
The
IETF
Trust
&
W3C
®
®
(
MIT
,
ERCIM
,
Keio
),
All
Rights
Reserved.
W3C
liability
,
trademark
and
document
use
rules
apply.
This document specifies XML digital signature processing rules and syntax. XML Signatures provide integrity , message authentication , and/or signer authentication services for data of any type, whether located within the XML that includes the signature or elsewhere.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is a W3C Last Call Working Draft of "XML Signature 2.0".
At the time of this publication, the XML Security WG is also producing "XML Signature Version 1.1". The most recent XML Signature Recommendation is the 10 June 2008 XML Signature (Second Edition) Recommendation .
This
document
is
expected
to
be
further
updated
based
on
both
Working
Group
input
and
public
comments.
An
updated
version
of
Canonical
XML
[
XML-C14N20
]
is
published
as
a
companion
document.
A diff-marked version of this specification that highlights changes against the previous version is available. Major changes in this version:
ds:Reference
URI
attribute.
Removed
EnvelopedSignature
parameter
from
XML
selection.
Revised
schema
and
discussion
related
to
dsig2:Verifications
element.
X509Data
element
into
2.0
schema
and
document.
This document was published by the XML Security Working Group as a Last Call Working Draft. This document is intended to become a W3C Recommendation. If you wish to make comments regarding this document, please send them to public-xmlsec@w3.org ( subscribe , archives ). The Last Call period ends 31 May 2011. All feedback is welcome.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
This is a Last Call Working Draft and thus the Working Group has determined that this document has satisfied the relevant technical requirements and is sufficiently stable to advance through the Technical Recommendation process.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy . W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .
ds:CryptoBinary
Simple
Type
Signature
element
SignatureValue
Element
SignedInfo
Element
Transforms
Reference
Element
URI
Attribute
dsig2:Selection
Transforms
Element
dsig2:Verification
dsig2:Selection
DigestValue
dsig2:Verifications
Element
KeyInfo
Element
KeyName
Element
KeyValue
Element
RetrievalMethod
Element
X509Data
Element
PGPData
Element
SPKIData
Element
MgmtData
Element
EncryptedKey
and
DerivedKey
Elements
DEREncodedKeyValue
dsig11:DEREncodedKeyValue
Element
KeyInfoReference
dsig11:KeyInfoReference
Element
Object
Element
Transform
Algorithm
dsig2:Selection
Algorithms
Selection
dsig2:Verification
CanonicalizationMethod
in
"Compatibility
Mode"
URI
Attribute
in
"Compatibility
Mode"
Transform
Algorithms
This section is non-normative.
This
document
specifies
XML
syntax
and
processing
rules
for
creating
and
representing
digital
signatures.
XML
Signatures
can
be
applied
to
any
digital
content
(data
object)
,
including
XML.
An
XML
Signature
may
be
applied
to
the
content
of
one
or
more
resources.
Enveloped
or
enveloping
signatures
are
over
data
within
the
same
XML
document
as
the
signature;
detached
signatures
are
over
data external
data
external
to
the
signature
element.
More
specifically,
this
specification
defines
an
XML
signature
element
type
and
an
XML
signature
application
;
conformance
requirements
for
each
are
specified
by
way
of
schema
definitions
and
prose
respectively.
This
specification
also
includes
other
useful
types
that
identify
methods
for
referencing
collections
of
resources,
algorithms,
and
keying
and
management
information.
The
XML
Signature
is
a
method
of
associating
a
key
with
referenced
data
(octets);
it
does
not
normatively
specify
how
keys
are
associated
with
persons
or
institutions,
nor
the
meaning
of
the
data
being
referenced
and
signed.
Consequently,
while
this
specification
is
an
important
component
of
secure
XML
applications,
it
itself
is
not
sufficient
to
address
all
application
security/trust
concerns,
particularly
with
respect
to
using
signed
XML
(or
other
data
formats)
as
a
basis
of
human-to-human
communication
and
agreement.
Such
an
application
must
specify
additional
key,
algorithm,
processing
and
rendering
requirements.
For
further
information,
please
see
section
12.
Security
Considerations
(section
8).
.
XML
Signature
2.0
includes
a
new
transform
Reference
processing
model
designed
to
address
additional
requirements
including
performance,
simplicity
and
streamability.
This
"2.0
mode"
model
is
significantly
different
than
in
the
XML
Signature
1.x.
1.x
model
in
that
it
explicitly
defines
selection,
canonicalization
and
verification
steps
for
data
processing
and
disallows
generic
transforms.
XML
Signature
2.0
is
designed
to
be
backward
compatible,
however,
enabling
compatible
through
the
inclusion
of
a
"Compatibility
Mode"
which
enables
the
XML
Signature
1.x
model
to
be
used
where
necessary.
Details
This
specification
defines
XML
Signature
2.0
which
differs
from
XML
Signature
1.x
in
some
specific
areas,
in
particular
the
use
of
this
model
are
documented
various
transform
algorithms
versus
a
fixed
2.0
transform
that
implies
the
use
of
Selection
and
Verification
steps
in
conjunction
with
ds:Reference
processing,
the
corresponding
disuse
of
the
URI
ds:Reference
attribute,
the
use
of
Canonical
XML
Signature,
Second
Edition.
2.0
[
XML-C14N20
]
in
place
of
other
canonicalization
algorithms,
and
updates
to
the
required
algorithms
and
other
changes.
This specification defines a "Compatibility Mode" that supports an XML Signature 1.x mode of operation. Compliance and other aspects unique to "Compatibility Mode" are outlined in section B. Compatibility Mode .
The body of the document refers to the syntax and processing model for the new 2.0 mode of operation, referred to as "XML Signature 2.0" in the document. Use of the "Compatibility Mode" is noted explicitly when required.
For
readability,
brevity,
and
historic
reasons
this
document
uses
the
term
"signature"
to
generally
refer
to
digital
authentication
values
of
all
types.
Obviously,
the
term
is
also
strictly
used
to
refer
to
authentication
values
that
are
based
on
public
keys
and
that
provide
signer
authentication.
When
specifically
discussing
authentication
values
based
on
symmetric
secret
key
codes
we
use
the
terms
authenticators
or
authentication
codes.
(See
section
12.2
Check
the
Security
Model
,
section
8.2.)
.)
This
specification
provides
a
normative
XML
Schema
Schemas
[
XMLSCHEMA-1
],
[
XMLSCHEMA-2
].
The
full
normative
grammar
is
defined
by
the
XSD
schema
schemas
and
the
normative
text
in
this
specification.
The
standalone
XSD
schema
file
is
files
are
authoritative
in
case
there
is
any
disagreement
between
it
them
and
the
XSD
schema
portions
in
this
specification.
The key words " must ", " must not ", " required ", " shall ", " shall not ", " should ", " should not ", " recommended ", " may ", and " optional " in this specification are to be interpreted as described in [ RFC2119 ].
"They must only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)"
Consequently, we use these capitalized key words to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. These key words are not used (capitalized) to describe XML grammar; schema definitions unambiguously describe such requirements and we wish to reserve the prominence of these terms for the natural language descriptions of protocols and features. For instance, an XML attribute might be described as being "optional." Compliance with the Namespaces in XML specification [ XML-NAMES ] is described as " required ."
The
design
philosophy
and
requirements
of
this
specification
are
addressed
in
the
original
XML-Signature
Requirements
document
[
XMLDSIG-REQUIREMENTS
]
and
],
the
XML
Security
1.1
Requirements
document
[
XMLSEC11-REQS
]
and
the
XML
Security
2.0
Requirements
document
[
XMLSEC2-REQS
].
This specification makes use of XML namespaces, and uses Uniform Resource Identifiers [ URI ] to identify resources, algorithms, and semantics.
Implementations of this specification must use the following XML namespace URIs:
URI | namespace prefix | XML internal entity |
---|---|---|
http://www.w3.org/2000/09/xmldsig#
|
default
namespace
,
ds:
,
dsig:
|
<!ENTITY
dsig
"http://www.w3.org/2000/09/xmldsig#">
|
http://www.w3.org/2009/xmldsig11#
|
dsig11:
|
<!ENTITY
dsig11
"http://www.w3.org/2009/xmldsig11#">
|
http://www.w3.org/2010/xmldsig2#
|
dsig2:
|
<!ENTITY
dsig2
"http://www.w3.org/2010/xmldsig2#">
|
While implementations must support XML and XML namespaces, and while use of the above namespace URIs is required , the namespace prefixes and entity declarations given are merely editorial conventions used in this document. Their use by implementations is optional .
These namespace URIs are also used as the prefix for algorithm identifiers that are under control of this specification. For resources not under the control of this specification, we use the designated Uniform Resource Names [ URN ], [ RFC3406 ] or Uniform Resource Identifiers [ URI ] defined by the relevant normative external specification.
For instance:
SignatureProperties
is
identified
and
defined
by
the
disg:
namespace
http://www.w3.org/2000/09/xmldsig#SignatureProperties
ECKeyValue
is
identified
and
defined
by
the
dsig11:
namespace
http://www.w3.org/2009/xmldsig11#ECKeyValue
http://www.w3.org/TR/1999/REC-xslt-19991116
Selection
is
identified
and
defined
by
the
dsig2:
namespace
http://www.w3.org/2010/xmldsig2#Selection
The
http://www.w3.org/2000/09/xmldsig#
(
dsig:
)
namespace
was
introduced
in
the
first
edition
of
this
specification,
and
http://www.w3.org/2009/xmldsig11#
(
dsig11:
)
namespace
was
introduced
in
1.1.
This
version
does
not
coin
any
new
elements
or
algorithm
identifiers
in
those
namespaces;
instead,
the
http://www.w3.org/2010/xmldsig2#
(
dsig2:
)
namespace
is
used.
No provision is made for an explicit version number in this syntax. If a future version of this specification requires explicit versioning of the document format, a different namespace will be used.
The
contributions
of
the
members
of
the
XML
Signature
Working
Group
to
the
first
edition
specification
are
gratefully
acknowledged:
Mark
Bartel,
Adobe,
was
Accelio
(Author);
John
Boyer,
IBM
(Author);
Mariano
P.
Consens,
University
of
Waterloo;
John
Cowan,
Reuters
Health;
Donald
Eastlake
3rd,
Motorola
Motorola;
(Chair,
Author/Editor);
Barb
Fox,
Microsoft
(Author);
Christian
Geuer-Pollmann,
University
Siegen;
Tom
Gindin,
IBM;
Phillip
Hallam-Baker,
VeriSign
Inc;
Richard
Himes,
US
Courts;
Merlin
Hughes,
Baltimore;
Gregor
Karlinger,
IAIK
TU
Graz;
Brian
LaMacchia,
Microsoft
(Author);
Peter
Lipp,
IAIK
TU
Graz;
Joseph
Reagle,
NYU,
was
W3C
(Chair,
Author/Editor);
Ed
Simon,
XMLsec
(Author);
David
Solo,
Citigroup
(Author/Editor);
Petteri
Stenius,
Capslock;
Raghavan
Srinivas,
Sun;
Kent
Tamura,
IBM;
Winchel
Todd
Vincent
III,
GSU;
Carl
Wallace,
Corsec
Security,
Inc.;
Greg
Whitehead,
Signio
Inc.
As are the first edition Last Call comments from the following:
The
following
members
of
the
XML
Security
Specification
Maintenance
Working
Group
contributed
to
the
second
edition:
Juan
Carlos
Cruellas,
Universitat
Politècnica
Politècnica
de
Catalunya;
Pratik
Datta,
Oracle
Corporation;
Phillip
Hallam-Baker,
VeriSign,
Inc.;
Frederick
Hirsch,
Nokia,
(Chair,
Editor);
Konrad
Lanz,
Applied
Information
processing
and
Kommunications
(IAIK);
Hal
Lockhart,
BEA
Systems,
Inc.;
Robert
Miller,
MITRE
Corporation;
Sean
Mullan,
Sun
Microsystems,
Inc.;
Bruce
Rich,
IBM
Corporation;
Thomas
Roessler,
W3C/ERCIM,
(Staff
contact,
Editor);
Ed
Simon,
W3C
Invited
Expert;
Greg
Whitehead,
HP.
Contributions
for
version
1.1
were
received
from
the
members
of
the
XML
Security
Working
Group:
Scott
Cantor,
Juan
Carlos
Cruellas,
Pratik
Datta,
Gerald
Edgar,
Ken
Graf,
Phillip
Hallam-Baker,
Brad
Hill,
Frederick
Hirsch
(Chair,
Editor),
Brian
LaMacchia,
Konrad
Lanz,
Hal
Lockhart,
Cynthia
Martin,
Rob
Miller,
Sean
Mullan,
Shivaram
Mysore,
Magnus
Nyström,
Nyström,
Bruce
Rich,
Thomas
Roessler,
Ed
Simon,
Chris
Solc,
John
Wray,
Kelvin
Yiu.
This section is non-normative.
This
section
provides
an
overview
and
examples
of
XML
digital
signature
syntax.
The
specific
processing
is
given
in
section
4.
Processing
Rules
(section
3).
.
The
formal
syntax
is
found
in
section
5.
Core
Signature
Syntax
(section
4)
and
section
9.
Additional
Signature
Syntax
(section
5).
.
In
this
section,
an informal
an
informal
representation
and
examples
are
used
to
describe
the
structure
of
the
XML
signature
syntax.
This
representation
and
examples
may
omit
attributes,
details
and
potential
features
that
are
fully
explained
later.
XML
Signatures
are
applied
to
arbitrary
digital
content
(data
objects)
via
an
indirection.
Data
objects
are
digested,
the
resulting
value
is
placed
in
an
element
(with
other
information)
and
that
element
is
then
digested
and
cryptographically
signed.
XML
digital
signatures
are
represented
by
the
Signature
element
which
has
the
following
structure
(where
"?"
denotes
zero
or
one
occurrence;
"+"
denotes
one
or
more
occurrences;
and
"*"
denotes
zero
or
more
occurrences):
<Signature ID?> <SignedInfo> <CanonicalizationMethod/> <SignatureMethod/> (<Reference URI? > (<Transforms>)? <DigestMethod> <DigestValue> </Reference>)+ </SignedInfo> <SignatureValue> (<KeyInfo>)? (<Object ID?>)* </Signature>
Signatures
are
related
to
data
objects
via
URIs
[
URI
].
Within
an
XML
document,
signatures
are
related
to
local
data
objects
via
fragment
identifiers.
Such
local
data
can
be
included
within
an
enveloping
signature
or
can
enclose
an
enveloped
signature.
Detached
signatures
are
over
external
network
resources
or
local
data
objects
that
reside
within
the
same
XML
document
as
sibling
elements;
in
this
case,
the
signature
is
neither
enveloping
(signature
is
parent)
nor
enveloped
(signature
is
child).
Since
a
Signature
element
(and
its
Id
attribute
value/name)
may
co-exist
or
be
combined
with
other
elements
(and
their
IDs)
within
a
single
XML
document,
care
should
be
taken
in
choosing
names
such
that
there
are
no
subsequent
collisions
that
violate
the
ID
uniqueness
validity
constraint
[
XML10
].
[s04]
The
SignatureMethod
is
the
algorithm
that
This
is
used
to
convert
the
canonicalized
SignedInfo
into
the
SignatureValue
.
It
is
a
combination
of
a
digest
algorithm
and
a
key
dependent
algorithm
and
possibly
other
algorithms
such
as
padding,
for
same
example
RSA-SHA1.
The
algorithm
names
are
signed
to
resist
attacks
based
on
substituting
a
weaker
algorithm.
To
promote
application
interoperability
we
specify
a
set
of
signature
algorithms
that
must
be
implemented,
though
their
use
is
at
the
discretion
of
the
signature
creator.
We
specify
additional
algorithms
as
recommended
or
optional
for
implementation;
the
design
also
permits
arbitrary
user
specified
algorithms.
[s05-11]
Each
Reference
element
includes
the
digest
method
and
resulting
digest
value
calculated
over
the
identified
data
object.
It
also
may
include
transformations
that
produced
the
input
to
the
digest
operation.
A
data
object
is
signed
by
computing
its
digest
value
and
a
signature
over
that
value.
The
signature
is
later
checked
via
reference
and
signature
validation
.
[s14-16]
KeyInfo
indicates
the
key
to
be
used
to
validate
the
signature.
Possible
forms
for
identification
include
certificates,
key
names,
and
key
agreement
algorithms
and
information
--
we
define
only
a
few.
KeyInfo
is
optional
for
two
reasons.
First,
the
signer
may
not
wish
to
reveal
key
information
to
all
document
processing
parties.
Second,
the
information
may
be
known
within
the
application's
context
and
need
not
be
represented
explicitly.
Since
KeyInfo
is
outside
of
SignedInfo
,
if
the
signer
wishes
to
bind
the
keying
information
to
the
signature,
a
Reference
can
easily
identify
and
include
the
KeyInfo
an
as
part
of
the
signature.
Use
of
KeyInfo
is
optional,
however
note
that
senders
and
receivers
must
agree
on
how
it
will
be
used
through
a
mechanism
out
of
scope
for
this
specification.
2.1.1
More
on
Reference
These
section
explaining
the
lines
[s05]
to
[s11]
of
the
previous
example.
This
signature
is
in
"compatibility
mode".
[s06]
[s07]
[s08]
[s09]
[s10]
[s11]
</Reference>
[s05]
The
optional
URI
attribute
of
Reference
identifies
the
data
object
to
be
signed.
This
attribute
may
be
omitted
on
at
most
one
Reference
in
a
Signature
.
(This
limitation
is
imposed
in
order
to
ensure
that
references
and
objects
may
be
matched
unambiguously.)
[s05-08]
This
identification,
along
with
the
transforms,
is
a
description
provided
by
the
signer
on
how
they
obtained
the
signed
data
object
in
the
form
it
was
digested
(i.e.
the
digested
content).
The
verifier
may
obtain
the
digested
content
in
another
method
so
long
as
the
digest
verifies.
In
particular,
the
verifier
may
obtain
the
content
from
a
different
location
such
as
a
local
store
than
that
specified
in
the
URI
.
[s06-08]
Transforms
is
an
optional
ordered
list
of
processing
steps
that
were
applied
to
for
the
resource's
content
before
it
was
digested.
Transforms
can
include
operations
such
as
canonicalization,
encoding/decoding
(including
compression/inflation),
XSLT,
XPath,
XML
schema
validation,
or
XInclude.
XPath
transforms
permit
the
signer
to
derive
an
Signature
1.x
,
but
for
XML
document
that
omits
portions
of
the
source
document.
Consequently
those
excluded
portions
can
change
without
affecting
signature
validity.
For
example,
if
the
resource
being
signed
encloses
the
signature
itself,
such
a
transform
must
be
used
to
exclude
the
signature
value
from
its
own
computation.
If
no
Transforms
element
is
present,
the
resource's
content
is
digested
directly.
While
the
Working
Group
has
specified
mandatory
(and
optional)
canonicalization
and
decoding
algorithms,
user
specified
transforms
are
permitted.
[s09-10]
DigestMethod
is
the
algorithm
applied
to
the
data
after
Transforms
is
applied
(if
specified)
to
yield
the
DigestValue
.
The
signing
of
the
DigestValue
is
what
binds
the
content
of
a
resource
to
the
signer's
key.
2.1.1.1
The
Simple
Example
in
"2.0
mode"
Here
is
the
same
signature
in
"2.0
mode".
Signature
2.0.
The
only
differences
are
in
the
CanonicalizationMethod
and
Reference
parts.
portions.
The
line
numbers
in
this
example
match
up
with
the
line
numbers
in
the
"compatibility
mode"
"Compatibility
Mode"
example.
[s01] <Signature Id="MyFirstSignature" xmlns="http://www.w3.org/2000/09/xmldsig#"> [s02] <SignedInfo> [s03] <CanonicalizationMethod Algorithm="http://www.w3.org/2010/xml-c14n2"/> [s04] <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> [s05] <Reference> [s06] <Transforms> [s07] <Transform Algorithm="http://www.w3.org/2010/xmldsig2#transform"> [s07a] <dsig2:Selection type="http://www.w3.org/2010/xmldsig2#xml" xmlns:dsig2="http://www.w3.org/2010/xmldsig2#" URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126"> > [s07b] </dsig2:Selection> [s07c] <CanonicalizationMethod Algorithm="http://www.w3.org/2010/xml-c14n2"/> [s07d] </Transform> [s08] </Transforms> [s09] <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> [s10] <DigestValue>dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...</DigestValue> [s11] </Reference> [s12] </SignedInfo> [s13] <SignatureValue>...</SignatureValue> [s14] <KeyInfo> [s15a] <KeyValue> [s15b] <DSAKeyValue> [s15c] <P>...</P><Q>...</Q><G>...</G><Y>...</Y> [s15d] </DSAKeyValue> [s15e] </KeyValue> [s16] </KeyInfo> [s17] </Signature>
[s03]
In
XML
Signature
2.0
mode,
the
Canonicalization
Method
URI
should
be
Canonical
XML
2.0
(or
a
later
version)
and
all
the
parameters
for
Canonical
XML
2.0
should
be
present
as
subelements
of
this
element.
element
[
XML-C14N20
].
[s05-s08]
Note
XML
Signature
2.0
mode
does
not
use
the
concept
of
various
transforms,
instead
each
reference
object
has
two
parts
-
a
element
to
choose
the
data
object
to
be
signed,
and
a
Selection
dsig2:Selection
Canonicalization
element
to
convert
the
data
object
to
a
canonicalized
octet
stream.
To
fit
in
these
two
elements,
without
breaking
backwards
compatibility
with
the
1.0
schema,
these
elements
have
been
put
inside
a
special
Transform
with
URI
.
In
XML
Signature
2.0
http://www.w3.org/2010/xmldsig2#newTransformModel
http://www.w3.org/2010/xmldsig2#transform
mode
the
Transforms
should
have
element
will
contain
only
have
this
particular
fixed
Transform
.
[s05]
In
the
"2.0
mode",
XML
Signature
2.0,
the
URI
attribute
should
be
is
omitted
from
the
Reference
.
Instead
it
should
can
be
found
in
the
.
Selection
dsig2:Selection
[s07a-s07b]
The
element
identifies
the
data
object
to
be
signed.
This
specification
identifies
only
Selection
dsig2:Selection
defines
two
types
types,
"xml"
and
"binary",
but
user
specified
types
are
also
allowed.
possible.
For
example
a
new
type
"database-rows"
can
could
be
defined
to
select
rows
from
the
a
database
for
signing.
Usually
a
URI
and
a
few
other
bits
of
information
is
are
used
to
identify
the
data
object,
but
the
URI
is
not
required,
required;
for
example
example,
the
"xml"
type
can
identify
a
local
document
subset
by
using
an
XPath.
[s07c]
The
CanonicalizationMethod
element
provides
the
mechanism
to
convert
the
data
object
into
a
canonicalized
octet
stream.
This
specification
only
addresses
only
canonicalization
for
xml
data.
Other
forms
of
canonicalization
can
be
defined
-
e.g.
a
scheme
for
signing
mime
attachments,
can
attachments
could
define
a
canonicalization
for
mime
headers
and
data.
The
output
of
the
canonicalization
is
digested.
This
specification
does
not
address
mechanisms
for
making
statements
or
assertions.
Instead,
this
document
defines
what
it
means
for
something
to
be
signed
by
an
The
followed
detailed
example
shows
XML
Signature
(
integrity
,
message
authentication
,
and/or
signer
authentication
).
Applications
that
wish
to
represent
other
semantics
must
rely
upon
other
technologies,
such
as
2.0
in
the
context
of
Web
Services
Security
[
XML10
WS-SECURITY11
],
[
RDF-PRIMER
].
For
instance,
showing
how
the
SOAP
body
can
be
referenced
using
an
application
might
use
a
foo:assuredby
attribute
within
its
own
markup
to
reference
a
Id
in
XML
Signature
element.
Consequently,
it's
2.0.
This
example
shows
more
detail
than
the
application
that
must
understand
and
know
how
to
make
trust
decisions
given
previous
Simple
XML
Signature
2.0
Example
.
Note:
This
example
(and
the
validity
of
next
example
using
XPath
)
show
the
signature
and
use
of
XML
Signature
2.0
in
the
meaning
context
of
Web
Services
Security.
This
is
illustrative
of
how
a
2.0
signature
could
be
substituted
for
an
1.x
Signature,
but
has
not
been
standardized
in
Web
Services
Security
so
should
only
be
considered
illustrative.
[ i01 ] <?xml version="1.0" encoding="UTF-8"?> [ i02 ] <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> [ i03 ] <soap:Header> [ i04 ] <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"> [ i05 ] <wsse:BinarySecurityToken wsu:Id="MyID" [ i06 ] ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" [ i07 ] EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#Base64Binary"> [ i08 ] MIIEZzCCA9CgAwIBAgIQEmtJZc0.. [ i09 ] </wsse:BinarySecurityToken> [ i10 ] <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> [ i11 ] <ds:SignedInfo> [ i12 ] <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2010/xml-c14n2" [ i13 ] xmlns:c14n2="http://www.w3.org/2010/xml-c14n2"> [ i14 ] <c14n2:IgnoreComments>true</c14n2:IgnoreComments> [ i15 ] <c14n2:TrimTextNodes>false</c14n2:TrimTextNodes> [ i16 ] <c14n2:PrefixRewrite>none</c14n2:PrefixRewrite> [ i17 ] <c14n2:QNameAware/> [ i18 ] </ds:CanonicalizationMethod> [ i19 ] <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> [ i20 ] <ds:Reference> [ i21 ] <ds:Transforms> [ i22 ] <ds:Transform Algorithm="http://www.w3.org/2010/xmldsig2#newTransformModel" xmlns:dsig2="http://www.w3.org/2010/xmldsig2#"> [ i23 ] <dsig2:Selection type="http://www.w3.org/2010/xmldsig2#xml" URI="#MsgBody" /> [ i24 ] <dsig2:Canonicalization > [ i25 ] <c14n2:IgnoreComments>true</c14n2:IgnoreComments> [ i26 ] <c14n2:TrimTextNodes>true</c14n2:TrimTextNodes> [ i27 ] <c14n2:PrefixRewrite>sequential</c14n2:PrefixRewrite> [ i28 ] <c14n2:QNameAware/> [ i29 ] </dsig2:Canonicalization> [ i30 ] <dsig2:Verifications> [ i31 ] <dsig2:Verification DigestDataLength="308"/> [ i32 ] </dsig2:Verifications> [ i33 ] </ds:Transform> [ i34 ] </ds:Transforms> [ i35 ] <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> [ i36 ] <ds:DigestValue>dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...</ds:DigestValue> [ i37 ] </ds:Reference> [ i38 ] </ds:SignedInfo> [ i39 ] <ds:SignatureValue>kdutrEsAEw56Sefgs34...</ds:SignatureValue> [ i40 ] <ds:KeyInfo> [ i41 ] <ds:KeyValue> [ i42 ] <wsse:SecurityTokenReference> [ i43 ] <wsse:Reference URI="#MyID"/> [ i44 ] </wsse:SecurityTokenReference> [ i45 ] </ds:KeyValue> [ i46 ] </ds:KeyInfo> [ i47 ] </ds:Signature> [ i48 ] </wsse:Security> [ i49 ] </soap:Header> [ i50 ] <soap:Body wsu:Id="MsgBody"> [ i51 ] <ex:operation xmlns:ex="http://www.example.com/"> [ i52 ] <ex:param1>42</ex:param1> [ i53 ] <ex:param2>43</ex:param2> [ i54 ] </ex:operation> [ i55 ] </soap:Body> [ i56 ] </soap:Envelope>
assuredby
[
i05-i09
]
syntax.
We
also
define
a
The
SignatureProperties
wsse:BinarySecurityToken
element
type
is
a
Web
Services
Security
mechanism
to
convey
key
information
needed
for
the
inclusion
of
assertions
about
the
signature
itself
(e.g.,
signature
semantics,
the
time
processing,
in
this
case
an
X.509v3
certificate.
[
i12-i18
]
This
example
shows
explicit
choices
for
parameters
of
signing
or
the
serial
number
of
hardware
used
in
cryptographic
processes).
Such
assertions
may
be
signed
by
including
a
rather
than
relying
on
implicit
defaults.
These
canonicalization
choices
are
for
the
canonicalization
of
Reference
ds:CanonicalizationMethod
SignatureProperties
ds:SignedInfo
in
using
Canonical
XML
2.0
[
XML-C14N20
].
The
SignedInfo
.
While
the
signing
application
should
be
very
careful
about
what
it
signs
(it
should
understand
what
is
in
the
[
i14
]
SignatureProperty
c14n2:IgnoreComments
)
a
receiving
application
has
no
obligation
parameter
is
set
to
understand
that
semantic
(though
its
parent
trust
engine
may
wish
to).
Any
content
about
true
,
the
signature
generation
may
default,
meaning
that
comments
will
be
located
within
the
ignored.
SignatureProperty
[
i15
]
element.
The
mandatory
Target
attribute
references
the
Signature
c14n2:TrimTextNodes
element
parameter
is
set
to
which
the
property
applies.
false
,
so
white
space
will
be
preserved.
Consider
the
preceding
example
(in
compatibility
mode)
with
an
additional
reference
to
a
local
Object
[
i16
]
that
includes
a
The
SignatureProperty
c14n2:PrefixRewrite
element.
(Such
a
signature
would
not
only
parameter
is
set
to
none
,
the
default,
meaning
that
no
prefixes
will
be
detached
rewritten.
[p02]
[
i17
]
but
enveloping
The
parameter
is
set
to
the
empty
set,
the
default,
meaning
that
no
QNames
require
special
processing.
[p03]
.)
c14n2:QNameAware
The
[p04]
[
i23
]
optional
Type
dsig2:Selection
attribute
of
Reference
URI
provides
information
about
parameter
is
set
to
#MsgBody
meaning
that
the
resource
identified
by
element
with
the
corresponding
Id
(in
this
case
)
will
be
selected.
URI
.
In
particular,
it
can
indicate
that
it
is
an
wsu:Id
The
Object
,
[
i24-i29
]
element
again
has
parameters
set
explicitly
for
SignatureProperty
,
or
dsig2:Canonicalization
canonicalization.
Manifest
ds:Reference
[
i30-i33
]
element.
This
example
uses
the
new
ability
in
XML
Signature
2.0
for
a
verifier
to
receive
constraint
information
that
can
be
used
by
applications
to
initiate
special
processing
verify
correctness
of
some
Reference
elements.
References
the
information
received,
to
an
XML
data
element
within
an
mitigate
against
attacks.
The
element
Object
dsig2:Verifications
should
identify
the
actual
element
pointed
to.
Where
the
element
content
is
not
XML
(perhaps
it
is
binary
or
encoded
data)
the
reference
should
identify
contains
this
verification
information.
In
this
case
the
Object
and
length
of
the
Reference
ds:Reference
Type
,
if
given,
should
indicate
Object
.
Note
data
that
Type
is
advisory
and
no
action
based
on
it
or
checking
of
its
correctness
was
digested
is
required
by
core
behavior.
conveyed.
Web
Services
Security
uses
its
[p13]
[
i42-i44
]
Object
SecurityTokenReference
is
mechanism
to
reference
key
information
conveyed
in
tokens,
such
as
an
optional
element
for
including
data
objects
within
X.509
certificate.
In
this
example
this
mechanism
is
used
to
reference
the
signature
element
or
elsewhere.
The
binary
security
token
at
Object
can
be
optionally
typed
and/or
encoded.
using
the
MyID
Id.
[p14-21]
[
i50
]
Signature
properties,
such
as
time
of
signing,
can
be
optionally
signed
by
identifying
them
from
within
a
The
has
Reference
.
(These
properties
are
traditionally
called
signature
"attributes"
although
that
term
soapBody
no
relationship
to
the
XML
term
"attribute".)
This
a
wsu:Id
attribute
which
is
the
same
example
in
the
2.0
mode.
Only
used
by
the
Reference
ds:Reference
part
is
different.
URI
attribute
to
reference
the
element.
The
Manifest
element
is
provided
followed
detailed
example
shows
use
of
XML
Signature
2.0
in
a
Web
Services
Security
example
similar
to
meet
additional
requirements
not
directly
addressed
by
the
mandatory
parts
previous
example
using
an
Id
reference
,
but
here
uses
an
XPath
expression
to
help
mitigate
the
possibility
of
wrapping
attacks.
In
this
specification.
Two
requirements
and
case
the
way
soap:Body
is
signed,
but
the
Manifest
ex:param2
satisfies
them
follow.
First,
applications
frequently
need
is
omitted
from
the
signature.
This
could
correspond
to
efficiently
sign
multiple
data
objects
even
a
case
where
the
signature
operation
itself
the
first
parameter
is
an
expensive
public
key
signature.
This
requirement
can
known
to
be
met
by
including
multiple
invariant
end-end
while
the
second
parameter
might
be
expected
to
change
as
the
SOAP
message
traverses
SOAP
intermediaries,
so
is
omitted
from
the
signature.
[ p01 ] <?xml version="1.0" encoding="UTF-8"?> [ p02 ] <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:ex="http://www.example.com/"> [ p03 ] <soap:Header> [ p04 ] <wsse:Security xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" [ p05 ] xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd"> [ p06 ] <wsse:BinarySecurityToken wsu:Id="MyID" [ p07 ] ValueType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3" [ p08 ] EncodingType="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#Base64Binary"> [ p09 ] MIIEZzCCA9CgAwIBAgIQEmtJZc0.. [ p10 ] </wsse:BinarySecurityToken> [ p11 ] <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> [ p12 ] <ds:SignedInfo> [ p13 ] <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2010/xml-c14n2" [ p14 ] xmlns:c14n2="http://www.w3.org/2010/xml-c14n2"> [ p15 ] <c14n2:IgnoreComments>true</c14n2:IgnoreComments> [ p16 ] <c14n2:TrimTextNodes>false</c14n2:TrimTextNodes> [ p17 ] <c14n2:PrefixRewrite>none</c14n2:PrefixRewrite> [ p18 ] <c14n2:QNameAware/> [ p19 ] </ds:CanonicalizationMethod> [ p20 ] <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> [ p21 ] <ds:Reference> [ p22 ] <ds:Transforms> [ p23 ] <ds:Transform Algorithm="http://www.w3.org/2010/xmldsig2#newTransformModel" xmlns:dsig2="http://www.w3.org/2010/xmldsig2#"> [ p24 ] <dsig2:Selection type="http://www.w3.org/2010/xmldsig2#xml" URI=""> [ p25 ] <dsig2:IncludedXPath>/soap:Envelope/soap:Body[1]</dsig2:IncludedXPath> [ p26 ] <dsig2:ExcludedXPath> [ p27 ] /soap:Envelope/soap:Body[1]/ex:operation[1]/ex:param2[1] [ p28 ] </dsig2:ExcludedXPath> [ p29 ] </dsig2:Selection> [ p30 ] <dsig2:Canonicalization > [ p31 ] <c14n2:IgnoreComments>true</c14n2:IgnoreComments> [ p32 ] <c14n2:TrimTextNodes>true</c14n2:TrimTextNodes> [ p33 ] <c14n2:PrefixRewrite>sequential</c14n2:PrefixRewrite> [ p34 ] <c14n2:QNameAware/> [ p35 ] </dsig2:Canonicalization> [ p36 ] <dsig2:Verifications> [ p37 ] <dsig2:Verification DigestDataLength="169"/> [ p38 ] </dsig2:Verifications> [ p39 ] </ds:Transform> [ p40 ] </ds:Transforms> [ p41 ] <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> [ p42 ] <ds:DigestValue>dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...</ds:DigestValue> [ p43 ] </ds:Reference> [ p44 ] </ds:SignedInfo> [ p45 ] <ds:SignatureValue>kdutrEsAEw56Sefgs34...</ds:SignatureValue> [ p46 ] <ds:KeyInfo> [ p47 ] <ds:KeyValue> [ p48 ] <wsse:SecurityTokenReference> [ p49 ] <wsse:Reference URI="#MyID"/> [ p50 ] </wsse:SecurityTokenReference> [ p51 ] </ds:KeyValue> [ p52 ] </ds:KeyInfo> [ p53 ] </ds:Signature> [ p54 ] </wsse:Security> [ p55 ] </soap:Header> [ p56 ] <soap:Body> [ p57 ] <ex:operation> [ p58 ] <ex:param1>42</ex:param1> [ p59 ] <ex:param2>43</ex:param2> [ p60 ] </ex:operation> [ p61 ] </soap:Body> [ p62 ] </soap:Envelope>
Reference
[
p24
]
elements
within
In
this
case
the
SignedInfo
URI
since
the
inclusion
attribute
of
each
digest
secures
the
data
digested.
However,
some
applications
may
not
want
the
core
validation
behavior
associated
with
this
approach
because
it
requires
every
Reference
within
element
is
as
XPath
is
used
rather
than
an
Id
based
reference.
SignedInfo
""
[
p25
]
The
dsig2:IncludedXPath
element
includes
an
XPath
expression
to
undergo
reference
validation
--
the
DigestValue
soap:Body
elements
are
checked.
These
applications
may
wish
element.
Note
that
this
expression
is
written
to
reserve
reference
validation
decision
logic
the
specific
soap:Body
to
themselves.
For
example,
mitigate
wrapping
attacks.
The
XPath
expression
is
an
application
might
receive
a
signature
valid
XML
Security
2.0
profile
of
XPath
1.0
[
XMLDSIG-XPATH
].
SignedInfo
[
p26
]
element
that
includes
three
The
Reference
dsig2:ExcludedXPath
elements.
If
a
single
element
specifies
that
the
Reference
ex:operation[1]/ex:param2[1]
fails
(the
identified
data
object
when
digested
does
not
yield
child
of
the
specified
DigestValue
soap:Body
)
not
be
included
in
the
signature
would
fail
core
validation
.
However,
signature.
The
XPath
expression
specifies
the
application
exact
instance
to
avoid
wrapping
attacks.
An
implementation
that
conforms
to
this
specification
must
be
conformant
to
XML
Signature
2.0
mode,
and
may
wish
be
conformant
to
treat
XML
Signature
1.1
Compatibility
Mode.
The following conformance requirements must be met by all implementations, including those in compatibility mode.
This section identifies algorithm conformance requirements applicable to both 2.0 and compatibility mode.
There
is
currently
no
consensus
on
mandatory
to
implement
algorithms;
the
signature
over
current
draft
text
represents
one
possible
outcome.
Positions
of
some
Working
Group
members
against
the
two
valid
Reference
elements
currently
expressed
set
of
mandatory
to
implement
algorithms
include:
Second,
consider
an
application
where
many
signatures
(using
different
keys)
are
applied
The
opposing
position
is
that,
going
forward,
this
specification
needs
to
a
large
number
have
credible
algorithm
agility
for
both
hash
and
public-key
algorithms:
Should
one
set
of
documents.
An
inefficient
solution
is
algorithms
prove
weak,
this
would
enable
a
quick
switch-over.
Therefore,
there
should
be
two
mandatory
to
implement
public-key
algorithms
from
different
families.
At
this
time,
elliptic
curve
based
algorithms
are
the
only
credible
contenders.
They
have
the
additional
benefit
of
providing
a
separate
reasonable
balance
between
key
sizes
and
security
level.
As
profiles
built
on
top
of
XML
Signature
that
currently
rely
on
DSA-SHA1
or
RSA-SHA1
as
the
only
supported
signature
(per
key)
repeatedly
applied
algorithm
will
need
to
be
updated
in
the
future,
the
Signature
core
specification
should
outline
a
large
clear
way
forward
in
terms
of
choice
of
algorithms.
This
choice
should
be
Elliptic
Curve
DSA.
Algorithms
are
identified
by
URIs
that
appear
as
an
attribute
to
the
element
that
identifies
the
algorithms'
role
(
,SignedInfo
DigestMethod
Transform
,
SignatureMethod
,
or
CanonicalizationMethod
element
(with
).
All
algorithms
used
herein
take
parameters
but
in
many
cases
the
parameters
are
implicit.
For
example,
a
Reference
SignatureMethod
s);
this
is
wasteful
implicitly
given
two
parameters:
the
keying
info
and
redundant.
A
more
efficient
solution
is
the
output
of
CanonicalizationMethod
.
Explicit
additional
parameters
to
include
many
references
in
an
algorithm
appear
as
content
elements
within
the
algorithm
role
element.
Such
parameter
elements
have
a
single
Manifest
that
descriptive
element
name,
which
is
then
referenced
from
multiple
frequently
algorithm
specific,
and
must
be
in
the
XML
Signature
elements.
namespace
or
an
algorithm
specific
namespace.
The
example
(in
compatibility
mode)
below
includes
a
Reference
that
signs
This
specification
defines
a
Manifest
found
within
set
of
algorithms,
their
URIs,
and
requirements
for
implementation.
Requirements
are
specified
over
implementation,
not
over
requirements
for
signature
use.
Furthermore,
the
Object
element.
mechanism
is
extensible;
alternative
algorithms
may
be
used
by
signature
applications.
Here
*note:
Note
that
the
same
URI
is
used
to
identify
base64
both
in
"encoding"
context
(e.g.
within
the
modified
element)
as
well
as
in
Reference
Object
2.0
mode
"transform"
context
(when
identifying
a
base64
transform).
The
sections
below
describe
the
operations
An
implementation
that
conforms
to
be
performed
as
part
of
signature
generation
this
specification
must
support
XML
Signature
2.0
operation
and
validation.
conform
to
the
following
features
when
not
operating
in
compatibility
mode:
URI
attribute
in
a
Reference
element
Reference
element
must
have
a
single
Transforms
,
as
determined
by
the
application,
to
the
data
object.
element
and
that
element
must
contain
exactly
one
Transform
element
with
an
Algorithm
of
"http://www.w3.org/2010/xmldsig2#transform"
Reference
must
be
an
octet
stream
with
the
digest
Reference
RetrievalMethod
.
dsig11:KeyInfoReference
This
section
identifies
algorithms
used
with
the
(optional)
identification
of
XML
digital
signature
specification.
Entries
contain
the
data
object,
any
(optional)
transform
identifier
to
be
used
in
Signature
elements,
a
reference
to
the
digest
algorithm
formal
specification,
and
definitions,
where
applicable,
for
the
DigestValue
.
(Note,
it
is
representation
of
keys
and
the
canonical
form
results
of
these
references
cryptographic
operations.
Note
that
the
algorithms
required
for
2.0
conformance
are
signed
in
3.1.2
fewer
than
for
compatibility
mode,
and
validated
that
some
algorithms
required
or
optional
are
disallowed
in
3.2.1
.)
2.0.
An
implementation
that
conforms
to
this
default
behavior,
but
explicitly
identify
specification
may
be
conformant
to
Compatibility
Mode.
To
conform
to
compatibility
mode
conformance
with
the
transformation
that
following
is
applied
required
as
well
as
conformance
to
perform
this
mapping.
In
cases
common
conformance
requirements
described
in
which
inclusive
canonicalization
section
3.1
Common
Conformance
Requirements
.
The
following
algorithm
support
is
desired,
we
RECOMMEND
that
required
for
compatibility
mode
(in
addition
to
those
required
for
all
modes).
**note:
The
Enveloped
Signature
transform
removes
the
Reference
Signature
element,
including
element
from
the
Selection
element,
Canonicalization
element,
calculation
of
the
digest
algorithm
and
signature
when
the
DigestValue
.
(Note,
it
signature
is
within
the
canonical
form
of
these
references
content
that
are
signed
in
3.1.2
and
validated
it
is
being
signed.
This
may
be
implemented
via
the
XPath
specification
specified
in
3.2.1
.)
XML
data
objects
6.6.4:
Enveloped
Signature
Transform
;
it
must
be
canonicalized
have
the
same
effect
as
that
specified
by
the
XPath
Transform.
When
using
Canonical
XML
transforms,
we
RECOMMEND
selecting
the
least
expressive
choice
that
still
accomplishes
the
needs
of
the
use
case
at
hand:
Use
of
XPath
filter
2.0
[
XML-C14N20
is
recommended
over
use
of
XPath
filter.
Use
of
XPath
filter
is
recommended
over
use
of
XSLT.
]
or
later.
Note:
Implementation
requirements
for
the
XPath
transform
may
be
downgraded
to
optional
in
a
future
version
of
this
specification.
The sections below describe the operations to be performed as part of signature generation and validation.
The
required
steps
include
the
generation
of
Reference
elements
and
the
SignatureValue
over
SignedInfo
.
SignedInfo
element
with
SignatureMethod
,
CanonicalizationMethod
and
Reference
(s).
SignatureValue
over
SignedInfo
based
on
algorithms
specified
in
SignedInfo
.
Signature
element
that
includes
SignedInfo
,
Object
(s)
(if
desired,
encoding
may
be
different
than
that
used
for
signing),
KeyInfo
(if
required),
and
SignatureValue
.
Note,
if
the
Signature
includes
same-document
references,
[
XML10
]
or
[
XMLSCHEMA-1
]
,[
XMLSCHEMA-2
]
validation
of
the
document
might
introduce
changes
that
break
the
signature.
Consequently,
applications
should
be
careful
to
consistently
process
the
document
or
refrain
from
using
external
contributions
(e.g.,
defaults
and
entities).
For each Reference:
dsig2:Selection
.
Canonicalization
to
convert
the
data
object
into
an
octet
stream.
This
is
not
required
for
binary
data.
Reference
element,
including
the
dsig2:Selection
element,
Canonicalization
element,
the
digest
algorithm
and
the
DigestValue
.
(Note,
it
is
the
canonical
form
of
these
references
that
are
signed
in
section
4.1
Signature
Generation
and
validated
in
section
4.4
Reference
Check
.)XML data objects must be canonicalized using Canonical XML 2.0 [ XML-C14N20 ] or an alternative algorithm that is compliant with its interface.
The required steps of core validation include
KeyInfo
.
(Note
in
some
environments,
the
signing
key
is
implicitly
known,
and
KeyInfo
is
not
used
at
all).
Reference
to
to
see
if
the
data
object
matches
with
the
expected
data
object.
SignedInfo
.
Reference
in
SignedInfo
.
Note, there may be valid signatures that some signature applications are unable to validate. Reasons for this include failure to implement optional parts of this specification, inability or unwillingness to execute specified algorithms, or inability or unwillingness to dereference specified URIs (some URI schemes may cause undesirable side effects), etc.
Comparison of each value in reference and signature validation is over the numeric (e.g., integer) or decoded octet sequence of the value. Different implementations may produce different encoded digest and signature values when processing the same resources because of variances in their encoding, such as accidental white space. But if one uses numeric or octet comparison (choose one) on both the stated and computed values these problems are eliminated.
The
absence
of
arbitrary
transforms
makes
Reference
reference
checking
much
more
simpler
in
2.0
mode.
In
this
mode
the
Dsig
library
should
XML
Signature
2.0.
Implementations
process
the
Selection
dsig2:Selection
of
in
each
Reference
to
return
a
list
of
data
objects
that
are
included
in
the
signature.
For
example
each
reference
in
a
signature
may
point
to
a
different
part
of
the
same
document.
The
signature
implementation
should
return
all
these
parts
(possibly
as
DOM
elements)
to
the
calling
application,
which
should
can
then
compare
them
against
its
policy
to
make
sure
what
was
expected
to
be
signed
is
actually
signed.
Signature
Reference
Validation
is
2.0
mode
is
very
similar,
except
that
in
this
mode
KeyInfo
cannot
have
any
transforms,
and
that
the
canonicalization
of
SignatureMethod
is
not
required.
These
are
the
steps.
Obtain
the
keying
information
from
KeyInfo
or
from
an
external
source.
Using
the
CanonicalizationMethod
(which
must
be
Canonical
XML
2.0)
and
use
the
result
(and
previously
obtained
KeyInfo
)
to
confirm
the
SignatureValue
over
the
SignedInfo
element.
3.2.5
Reference
Validation
in
compatibility
mode
Canonicalize
the
SignedInfo
element
based
on
the
CanonicalizationMethod
in
SignedInfo
.
For
each
Reference
in
SignedInfo
:
Obtain
the
data
object
similar
to
be
digested.
(For
example,
the
signature
application
may
dereference
the
URI
and
execute
Transforms
provided
by
the
signer
in
the
Reference
element,
or
it
may
obtain
the
content
through
other
means
such
as
a
local
cache.)
Digest
the
resulting
data
object
using
the
DigestMethod
specified
in
its
Reference
specification.
Compare
the
generated
digest
value
against
DigestValue
in
the
SignedInfo
Reference
;
if
there
is
any
mismatch,
validation
fails.
Note,
SignedInfo
is
canonicalized
in
step
1.
The
application
must
ensure
that
the
CanonicalizationMethod
has
no
dangerous
side
effects,
such
as
rewriting
URIs,
(see
CanonicalizationMethod
Note
(section
4.4.1))
and
that
it
Sees
What
is
Signed
,
which
is
the
canonical
form.
Note,
After
a
Signature
element
has
been
created
in
Signature
Generation
for
a
signature
with
a
same
document
reference,
an
implementation
can
serialize
the
XML
content
with
variations
in
that
serialization.
This
means
that
Reference
Validation
needs
to
canonicalize
the
XML
document
before
digesting
in
step
1
to
avoid
issues
related
to
variations
in
serialization.
3.2.6
Reference
Validation
in
2.0
mode
Reference
Validation
in
2.0
mode
is
very
similar,
Signature
1.x,
except
that
the
SignedInfo
need
not
be
canonicalized,
there
are
no
arbitrary
transforms
to
execute,
and
there
is
an
optional
step.
dsig2:Verification
dsig2:Verifications
Reference
in
SignedInfo
:
Selection
dsig2:Selection
.
dsig2:Verification
element
with
dsig2:IDAssertion
subelement,
Type="http://www.w3.org/2010/xmldsig2#IDAttributes"
,
then
dsig2:Verification
element
with
dsig2:PositionAssertion
subelement,
Type="http://www.w3.org/2010/xmldsig2#PositionAssertion"
,
then
PositionAssertion
attribute.
Canonicalization
to
compute
an
octet
stream.
dsig2:Verification
element
with
dsig2:DigestDataLength
subelement,
Type="http://www.w3.org/2010/xmldsig2#DigestDataLength"
,
then
verify
that
the
length
of
the
octet
stream
computed
above
is
the
same
as
the
length
specified
in
DigestDataLength
attribute.
DigestMethod
specified
in
its
Reference
specification.
The
canonicalization
and
digesting
can
be
combined
in
one
step
for
efficiency.
DigestValue
in
the
SignedInfo
Reference
;
if
there
is
any
mismatch,
validation
fails.
Signature
Validation
in
XML
Signature
2.0
is
very
similar
to
XML
Signature
1.x,
except
that
KeyInfo
cannot
contain
any
transforms,
and
the
canonicalization
of
SignatureMethod
is
not
required.
These
are
the
steps.
KeyInfo
or
from
an
external
source.
CanonicalizationMethod
(which
must
be
Canonical
XML
2.0
or
an
alternative
algorithm
that
is
compliant
with
its
interface)
and
use
the
result
(and
previously
obtained
KeyInfo
)
to
confirm
the
SignatureValue
over
the
SignedInfo
element.
The
general
structure
of
an
XML
signature
Signature
is
described
in
section
2.
Signature
Overview
(section
2).
and
Examples
.
This
section
provides
detailed
syntax
of
the
core
signature
features.
Features
described
in
this
section
are
mandatory
to
implement
unless
otherwise
indicated.
The
syntax
is
defined
via
an
XML
Schema
[
XMLSCHEMA-1
][
XMLSCHEMA-2
]
with
the
following
XML
preamble,
declaration,
and
internal
entity.
Schema Definition: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE schema PUBLIC "-//W3C//DTD XMLSchema 200102//EN" "http://www.w3.org/2001/XMLSchema.dtd" [ <!ATTLIST schema xmlns:ds CDATA #FIXED "http://www.w3.org/2000/09/xmldsig#"> <!ENTITY dsig 'http://www.w3.org/2000/09/xmldsig#'> <!ENTITY % p ''> <!ENTITY % s ''> ]> <schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" targetNamespace="http://www.w3.org/2000/09/xmldsig#" version="0.1" elementFormDefault="qualified">
Additional
markup
defined
in
version
1.1
of
this
specification
uses
the
dsig11:
namespace.
The
syntax
is
defined
in
an
XML
schema
with
the
following
preamble:
<?xml version="1.0" encoding="utf-8"?> <!DOCTYPE schema PUBLIC "-//W3C//DTD XMLSchema 200102//EN" "http://www.w3.org/2001/XMLSchema.dtd" [ <!ENTITY dsig 'http://www.w3.org/2000/09/xmldsig#'> <!ENTITY dsig11 'http://www.w3.org/2009/xmldsig11#'> <!ENTITY % p ''> <!ENTITY % s ''> ]> <schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsig11="http://www.w3.org/2009/xmldsig11#" targetNamespace="http://www.w3.org/2009/xmldsig11#" version="0.1" elementFormDefault="qualified">
Finally,
markup
defined
by
version
2.0
of
this
specification
uses
the
dsig2:
namespace.
The
syntax
is
defined
in
an
XML
schema
with
the
following
preamble:
<?xml version="1.0" encoding="utf-8"?> <schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:ds="http://www.w3.org/2000/09/xmldsig#" xmlns:dsig11="http://www.w3.org/2009/xmldsig11#" xmlns:dsig2="http://www.w3.org/2010/xmldsig2#" targetNamespace="http://www.w3.org/2010/xmldsig2#" version="0.1" elementFormDefault="qualified">
Notwithstanding the presence of a mixed content model (via mixed="true" declarations) in the definitions of various elements that follow, use of mixed content in conjunction with any elements defined by this specification is not recommended .
When
these
elements
are
used
in
conjunction
with
"2.0
Mode"
XML
Signature
2.0
signatures,
mixed
content
must
not
be
used.
ds:CryptoBinary
Simple
Type
This
specification
defines
the
ds:CryptoBinary
simple
type
for
representing
arbitrary-length
integers
(e.g.
"bignums")
in
XML
as
octet
strings.
The
integer
value
is
first
converted
to
a
"big
endian"
bitstring.
The
bitstring
is
then
padded
with
leading
zero
bits
so
that
the
total
number
of
bits
==
0
mod
8
(so
that
there
are
an
integral
number
of
octets).
If
the
bitstring
contains
entire
leading
octets
that
are
zero,
these
are
removed
(so
the
high-order
octet
is
always
non-zero).
This
octet
string
is
then
base64
[
RFC2045
]
encoded.
(The
conversion
from
integer
to
octet
string
is
equivalent
to
IEEE
1363's
I2OSP
[
IEEE1363
]
with
minimal
length).
This
type
is
used
by
"bignum"
values
such
as
RSAKeyValue
and
DSAKeyValue
.
If
a
value
can
be
of
type
base64Binary
or
ds:CryptoBinary
they
are
defined
as
base64Binary
.
For
example,
if
the
signature
algorithm
is
RSA
or
DSA
then
.
SignatureValue
represents
a
bignum
and
could
would
be
ds:CryptoBinary
.
However,
if
HMAC-SHA1
is
the
signature
algorithm
then
SignatureValue
could
have
leading
zero
octets
that
must
be
preserved.
Thus
SignatureValue
is
generically
defined
as
of
type
base64Binary
.
Schema Definition: <simpleType name="CryptoBinary"> <restriction base="base64Binary"> </restriction> </simpleType>
Signature
element
The
Signature
element
is
the
root
element
of
an
XML
Signature.
Implementation
must
generate
laxly
schema
valid
[
XMLSCHEMA-1
][
XMLSCHEMA-2
]
Signature
elements
as
specified
by
the
following
schema:
Schema Definition: <element name="Signature" type="ds:SignatureType"/> <complexType name="SignatureType"> <sequence> <element ref="ds:SignedInfo"/> <element ref="ds:SignatureValue"/> <element ref="ds:KeyInfo" minOccurs="0"/> <element ref="ds:Object" minOccurs="0" maxOccurs="unbounded"/> </sequence> <attribute name="Id" type="ID" use="optional"/> </complexType>
SignatureValue
Element
The
SignatureValue
element
contains
the
actual
value
of
the
digital
signature;
it
is
always
encoded
using
base64
[
RFC2045
].
Schema Definition: <element name="SignatureValue" type="ds:SignatureValueType"/> <complexType name="SignatureValueType"> <simpleContent> <extension base="base64Binary"> <attribute name="Id" type="ID" use="optional"/> </extension> </simpleContent> </complexType>
SignedInfo
Element
The
structure
of
SignedInfo
includes
the
a
canonicalization
algorithm,
a
signature
algorithm,
and
one
or
more
references.
Given
the
importance
of
reference
processing,
this
is
described
separately
in
section
6.
Referencing
Content
.
The
SignedInfo
element
may
contain
an
optional
ID
attribute
that
will
allow
allowing
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>
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
section
3.2.1
XML
Signature
2.0
Algorithm
Identifiers
and
Implementation
Requirements
(section
6.1).
.
Implementations
must
support
the
required
canonicalization
algorithms
.
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>
In
2.0
mode
XML
Signature
2.0,
the
SignedInfo
element
is
presented
as
a
single
subtree
with
no
exclusions
to
the
Canonicalization
2.0
algorithm.
All
the
subelements
of
Canonicalization
are
presented
as
parameters.
2.0
mode
uses
CanonicalizationMethod
in
more
way
-
as
a
canonicalization
for
the
Reference
.
The
rest
of
the
section
is
only
applicable
for
compatibility
mode.
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
XML-C14N20
]
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
algorithm.
Parameters
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
algorithm
are
represented
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
subelements
of
the
Reference
Canonicalization
s
being
validated.
Or,
element.
XML
Signature
2.0
signatures
use
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
express
the
desired
key,
DigestMethod
,
and
SignatureMethod
,
can
be
meaningless
if
a
capricious
canonicalization
of
each
.
CanonicalizationMethod
is
used.
Reference
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:
3.2.1
XML
Signature
2.0
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.
Reference
DigestMethod
Element
is
Reference
DigestMethod
an
a
required
element
that
may
occur
one
or
more
times.
It
specifies
a
identifies
the
digest
algorithm
to
be
applied
to
the
signed
object.
This
element
uses
the
general
structure
here
for
algorithms
specified
in
section
3.2.1
XML
Signature
2.0
Algorithm
Identifiers
and
digest
value,
Implementation
Requirements
.
For
"Compatibility
Mode"
signatures,
if
the
result
of
the
URI
dereference
and
optionally
an
identifier
application
of
Transforms
is
an
XPath
node-set
(or
sufficiently
functional
replacement
implemented
by
the
object
being
signed,
application)
then
it
must
be
converted
as
described
in
section
B.4.1
The
"Compatibility
Mode"
Reference
Processing
Model
.
If
the
type
result
of
the
object,
and/or
a
list
URI
dereference
and
application
of
transforms
to
Transforms
is
an
octet
stream,
then
no
conversion
occurs
(comments
might
be
present
if
Canonical
XML
with
Comments
was
specified
in
the
Transforms
).
The
digest
algorithm
is
applied
prior
to
digesting.
The
identification
(URI)
and
transforms
describe
how
the
digested
content
(i.e.,
data
octets
of
the
input
to
resulting
octet
stream.
For
XML
Signature
2.0
signatures,
the
result
of
processing
the
digest
method)
was
created.
The
Type
Reference
attribute
facilitates
the
processing
of
referenced
data.
For
example,
while
this
specification
makes
no
requirements
over
external
data,
is
an
application
may
wish
to
signal
that
octet
stream,
and
the
referent
digest
algorithm
is
a
applied
to
the
resulting
data
octets.
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>
Manifest
.
An
optional
ID
attribute
permits
a
DigestValue
Element
Reference
DigestValue
to
be
referenced
from
elsewhere.
Schema Definition:
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>
The
XML
Signature
2.0
Specification
specification
is
designed
to
support
a
new,
simplified
processing
model
while
remaining
backwardly
compatible
backwardly-compatible
with
the
older
1.x
processing
model.
These
are
termed
"2.0
Mode"
and
model
through
optional
support
of
a
"Compatibility
Mode"
respectively.
defined
in
a
separate
section
of
this
document,
section
B.
Compatibility
Mode
.
A
generic
signature
processor
can
determine
the
mode
of
a
signature
by
examining
the
Reference
element's
attributes
and
the
child
element(s)
of
the
Transforms
element.
element
(if
any).
If
the
URI
attributes
is
present,
"Compatibility
Mode"
is
used.
can
be
assumed.
If
the
URI
attribute
is
not
present,
and
the
attributes
Transforms
element
contains
exactly
one
Transform
element
with
an
Algorithm
of
,
then
"http://www.w3.org/2010/xmldsig2#newTransformModel"
"http://www.w3.org/2010/xmldsig2#transform"
"2.0
Mode"
is
used.
XML
Signature
2.0
processing
can
be
assumed.
Otherwise,
"Compatibility
Mode"
is
used.
applied.
All
the
references
of
a
signature
should
have
the
same
mode,
mode;
i.e.
they
should
all
be
in
2.0
mode,
XML
Signature
2.0,
or
all
be
in
Compatibility
mode.
"Compatibility
Mode".
URI
Attribute
for
Reference
In
"Compatibility
mode"
at
most
one
Reference
is
an
element
without
a
URI
attribute
that
may
be
present
in
any
particular
SignedInfo
,
occur
one
or
Manifest
.
The
remainder
of
this
section
applies
only
to
"Compatibility
Mode".
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
].
more
times.
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
specifies
a
URI
in
the
HTTP
scheme
must
comply
with
the
Status
Code
Definitions
of
[
HTTP11
]
(e.g.,
302,
305
digest
algorithm
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
digest
value,
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
optionally
an
identifier
of
the
object
is
part
of
the
application
context.
In
Compatibility
mode,
this
attribute
may
be
omitted
from
at
most
one
Reference
in
any
particular
SignedInfo
,
or
Manifest
.
The
optional
Type
attribute
contains
information
about
being
signed,
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
object,
and/or
a
SignatureProperties
element
is
still
of
type
#Object
.
The
Type
attribute
is
advisory.
No
validation
list
of
the
type
information
is
required
by
this
specification.
4.4.3.3
The
"Compatibility
Mode"
Reference
Processing
Model
Note
:
XPath
is
recommended
.
Signature
applications
need
not
conform
to
[
XPATH
]
specification
in
order
transforms
to
conform
be
applied
prior
to
this
specification.
However,
the
XPath
data
model,
definitions
(e.g.,
node-sets
)
digesting.
The
identification
(URI)
and
syntax
is
used
within
this
document
in
order
to
transforms
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
how
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
digested
content
(i.e.,
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:
method)
was
created.
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
Type
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
facilitates
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
of
referenced
data.
For
example,
while
this
specification
makes
no
requirements
over
external
resources
since
the
data,
an
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
wish
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
signal
that
represent
the
external
resource
'http://example.com/bar.xml',
that
referent
is
probably
an
XML
document
given
its
file
extension.
a
.
An
optional
ID
attribute
URI="http://example.com/bar.xml#chapter1"
Identifies
the
element
with
Manifest
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
permits
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"
Reference
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.
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>
URI
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
be
omitted
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).
XML
Signature
2.0
signatures.
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.
Each
Transform
consists
of
an
Algorithm
attribute
and
content
parameters,
if
any,
appropriate
for
the
given
algorithm.
The
Algorithm
Reference
attribute
value
specifies
the
name
of
the
algorithm
to
be
performed,
and
must
contain
the
Transform
Transforms
content
provides
additional
data
to
govern
the
algorithm's
processing
of
the
transform
input.
(See
Algorithm
Identifiers
element,
and
Implementation
Requirements
(section
6).)
If
the
Transforms
element
is
present
this
must
contain
one
and
contains
exactly
only
one
Transform
element
with
an
Algorithm
of
.
This
signals
the
"http://www.w3.org/2010/xmldsig2#newTransformModel"
,
then
"2.0
Mode"
is
used.
Otherwise,
"Compatibility
Mode"
is
used.
The
following
two
sections
detail
"http://www.w3.org/2010/xmldsig2#transform"
use
of
this
element
2.0
syntax
and
processing
(Compatibility
mode
transforms
are
described
in
each
case.
Schema Definition:
4.4.3.6
The
section
B.5
"Compatibility
Mode"
Transforms
and
Processing
Model
In
this
mode,
the
Transforms
element
is
optional
and
its
presence
indicates
that
the
signer
is
not
signing
the
native
(original)
document
but
the
resulting
(transformed)
document.
(See
Only
What
is
Signed
is
Secure
(section
8.1).)
).
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>
The
output
semantics
of
each
Transform
serves
as
input
to
the
next
Transform
.
The
input
to
the
first
Transform
element
in
XML
Signature
2.0
is
the
result
of
dereferencing
that
its
input
is
determined
solely
from
within
the
URI
Transform
attribute
of
itself
rather
than
via
the
surrounding
Reference
.
The
output
element.
from
the
last
Transform
is
the
input
for
the
DigestMethod
algorithm.
As
described
in
The
"Compatibility
Mode"
Reference
Processing
Model
(section
4.4.3.2),
some
transforms
take
an
XPath
node-set
as
input,
while
others
require
guaranteed
to
be
an
octet
stream.
If
the
actual
input
matches
the
input
needs
of
the
transform,
then
the
transform
operates
on
the
unaltered
input.
If
the
transform
input
requirement
differs
from
the
format
of
the
actual
input,
then
the
input
must
be
converted.
Some
Transform
s
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
detailed
definition
of
the
XML
Signature
2.0
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
algorithm
definitions
can
be
verifiable
outside
of
their
application
domain.
found
in
section
10.5
The
Transform
Algorithms
(section
6.6)
defines
the
list
of
standard
transformations.
Algorithm
.
In
"2.0
Mode"
signatures,
A
difference
from
XML
Signature
1.x
(and
the
corresponding
"Compatibility
Mode")
is
that
the
use
of
extensible
Transform
algorithms
is
replaced
with
a
construct
that
combines
selection
of
the
content
to
sign,
and
canonicalization,
into
a
single
unit
with
an
extensible
syntax
for
reference
and
selection
processing.
This
construct
is
modeled
as
special
a
fixed
Transform,
so
as
not
for
compatibility
with
the
original
schema,
and
to
break
existing
schema.
ensure
predictable
failure
modes
for
older
implementations.
This
special
Transform
has
an
Algorithm
of
"http://www.w3.org/2010/xmldsig2#newTransformModel"
.
In
2.0
signatures,
each
Reference
must
contain
the
Transforms
element,
and
this
must
contain
just
one
transform
-
this
one.
Legacy
implementations
will
should
react
to
this
as
an
undefined
Transform
and
report
failure
in
the
fashion
that
is
normal
for
algorithm
them.
The
semantics
of
the
"2.0
Mode"
Transform
are
them
in
such
that
its
input
is
determined
solely
from
within
the
Transform
itself
rather
than
via
the
surrounding
Reference
element.
The
output
is
guaranteed
to
be
an
octet
stream.
The
special
Transform
element
consists
of
a
required
dsig2:Selection
element
followed
by
an
optional
CanonicalizationMethod
element
and
an
optional
dsig2:Verification
element.
case.
dsig2:Selection
Element
The
dsig2:Selection
element
describes
the
data
being
signed
for
a
"2.0
Mode"
signature
reference.
Reference
.
The
content
and
processing
model
for
this
element
depends
on
the
value
of
the
required
Type
and
an
optional
SubType
Algorithm
attributes,
attribute,
which
identifies
the
selection
algorithm
algorithm/syntax
in
use.
The
other
attributes
of
required
attribute
and
any
dsig2:Selection
URI
subelements
child
elements
are
passed
in
to
that
algorithm
as
parameters
to
the
selection
processing.
Schema Definition: <xs:element name="Selection" type="dsig2:SelectionType"/> <xs:complexType name="dsig2:SelectionType"> <xs:sequence> <xs:any namespace="##any" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:attribute name="URI" type="xs:anyURI" use="required"/> <xs:attribute name="Algorithm" type="xs:anyURI" use="required"/> </xs:complexType>
The
Type
(and
optionally
the
SubType
Algorithm
)
attribute
is
an
extensibility
point
and
users
are
allowed
to
add
their
own
types.
enabling
application-specific
content
selection
approaches.
Each
type/subtype
should
Algorithm
must
define
the
parameters
that
is
expects,
expected,
how
they
are
laid
out
inside
expressed
within
the
element,
how
to
process
the
Selection
dsig2:Selection
Selection,
selection,
what
user
defined
user-defined
object
does
the
selection
produce,
produces,
and
what
canonicalization
algorithm
to
use
algorithm(s)
to
canonicalize
it
allow
for
unambiguous
conversation
of
the
data
into
an
octet
stream.
The
following
values
of
Type
and
SubType
are
defined
by
this
specification.
Type="http://www.w3.org/2010/xmldsig2#xml"
:
Select
complete
XML
documents,
or
XML
fragments.
Type
=
"http://www.w3.org/2010/xmldsig2#binary"
and
Subtype
=
"http://www.w3.org/2010/xmldsig2#fromURI"
:
Select
binary
data
from
an
external
URI.
Type
=
"http://www.w3.org/2010/xmldsig2#binary"
and
Subtype
=
"http://www.w3.org/2010/xmldsig2#fromBase64Node"
:
Select
binary
data
from
a
base64
encoded
text
node
inside
an
XML
document.
These
algorithms
are
defined
in
2.0
Mode
Selection
Algorithms
.
Users
can
define
new
types,
e.g.
they
can
define
a
"text"
type
with
associated
text
canonicalization,
or
they
can
define
a
"DataBase
rowset"
type
to
sign
database
content.
The
result
of
processing
the
dsig2:Selection
element
must
be
one
of
the
following:
In
the
first
case,
the
current
Signature
node
is
implicitly
added
as
an
exclusion,
and
then
a
"2.0
Mode"
canonicalization
algorithm
(one
compatible
with
these
inputs
inputs)
must
be
applied
to
produce
an
octet
stream
for
the
digest
algorithm.
The
contents
of
the
sibling
CanonicalizationMethod
element,
if
present,
will
specify
the
algorithm
to
use,
and
supply
any
non-default
parameters
to
that
algorithm.
If
no
sibling
CanonicalizationMethod
element
is
present,
then
the
XML
Canonicalization
2.0
Algorithm
[
XML-C14N20
]
must
be
used
applied
with
no
non-default
parameters.
For
an
octet
stream,
no
further
processing
is
applied
to
applied,
and
the
resulting
octet
stream,
which
will
be
octets
are
supplied
directly
to
the
digest
algorithm.
The
dsig2:Verification
is
an
optional
element
that
will
contain
information
to
help
in
signature
Verification.
It
will
contain
the
following
subelements,
each
of
which
can
be
present
at
most
once,
but
in
any
order.
<dsig2:DigestDataLength>
which
is
an
integer
that
specifies
the
number
of
bytes
that
were
digested
in
this
reference.
This
can
be
used
for
multiple
purposes,
a)
to
debug
digest
verification
failures,
b)
to
indicate
intentional
signing
of
0
bytes,
this
can
happen
if
an
XPath
expression
did
not
choose
anything,
c)
to
bypass
the
expensive
digest
calculation
if
the
during
verification
the
computed
length
doesn't
match
length
found
in
reference.
<dsig2:PositionAssertion>
is
used
to
enable
ID-based
referencing
that
is
more
resistant
to
signature
wrapping
attacks.
It
contains
an
XPath
expression
that
has
to
match
the
referenced
content's
position
in
the
document.
This
way,
instead
of
"selecting"
the
referenced
element
via
XPath
we
just
"verify"
its
position
(which
then
is
way
more
flexible
in
terms
of
what
is
really
enforced),
but
stick
to
ID-based
referencing
in
selection.
<dsig2:IDAttributes>
is
used
for
ID-based
references
to
precisely
define
the
ID
attribute
that
the
signer
has
used
for
a
particular
reference.
It
can
have
one
of
the
following
two
subelements:
<dsig2:QualifiedID
name="..."
ns="..."/>
to
define
a
namespace
qualified
ID
attributes.
The
localname
and
the
namespace
URI
of
the
ID
attribute
needs
to
be
specified.
<dsig2:UnqualifiedID
name="..."
parentname="..."
parentns="..."/>
to
define
unqualified
ID
attributes.
This
needs
the
localname
of
the
ID
attribute,
the
localname
of
the
owner
element
(i.e.
the
element
that
is
the
parent
of
the
ID
attribute)
and
the
namespace
URI
of
the
owner
element.
Without
a
DTD,
there
is
technically
no
way
to
define
IDness
in
an
XML
document.
In
practice,
this
typing
was
extended
to
documents
validated
by
an
XML
Schema,
and
then
to
the
creation
of
xml:id
.
Unfortunately,
DTDs
have
mostly
fallen
out
of
practice,
and
schemas
are
expensive,
rarely
used
in
many
runtime
scenarios,
and
can't
be
counted
in
to
be
completely
known
by
the
verifying
entity
in
the
presence
of
extensible
XML
scenarios.
xml:id
has
not
seen
wide
adoption
yet,
mainly
because
For
a
lot
of
the
standards
that
needed
it
(SAML,
WS-Security)
predated
it.
The
user-defined
object
(the
result
of
all
this
is
that
applications
that
rely
on
ID-based
references
for
signing
have
typically
made
insecure
assumptions
about
the
IDness
of
attributes
based
on
their
name
(
ID
,
id
,
Id
,
etc.),
or
have
to
provide
APIs
for
applications
to
call
before
verification
(which
is
also
a
problem
for
extensibility).
DOM
level
3,
which
user-defined
selection
process),
processing
is
now
fairly
widely
implemented,
also
provides
the
ability
subject
to
identify
attributes
as
an
ID
at
runtime,
although
often
without
guaranteeing
the
uniqueness
property.
This
<dsig2:IDAttributes>
element
provides
a
deterministic
way
definition
of
defining
the
ID,
that
is
independent
of
DTD,
XML
Schema,
DOM
3
or
any
application
specific
mechanism.
process.
Signature
2.0
does
Signatures
in
"2.0
Mode"
do
not
use
an
XPath
nodeset
to
represent
an
deal
with
XML
fragment
content
to
be
signed.
Instead
it
uses
signed
in
terms
of
an
XPath
nodeset.
Instead,
the
following
concept:
interface
is
used:
URI
Attribute
for
Selection
in
2.0
mode
In
"2.0
Mode",
the
URI
attribute
must
be
omitted
in
Reference
dsig2:Verifications
The
Selection
's
URI
attribute
is
a
a
slightly
simplified
version
of
the
Reference
's
URI
Dereferencing
is
carried
out
in
the
context
of
the
Selection
,
i.e
if
the
Type
is
"http://www.w3.org/2010/xmldsig2#xml"
,
then
the
URI
is
dereferenced
and
then
parsed
into
an
XML
document,
whereas
if
the
Type
is
"http://www.w3.org/2010/xmldsig2#binary"
and
SubType
is
"http://www.w3.org/2010/xmldsig2#fromURI"
dsig2:Verifications
then
the
URI
is
dererefenced
as
an
octet
stream.
Other
user
defined
Type
can
specify
different
dereferencing
mechanisms.
Dereferencing
a
same-document
reference
does
not
result
in
a
XPath
node
set.
As
mentioned
in
the
previous
bullet,
referencing
is
in
the
context
of
the
Selection
.
In
Type="http://www.w3.org/2010/xmldsig2#xml"
same
document
reference
results
in
the
entire
document
if
URI=""
or
in
a
subtree
is
the
URI
refers
to
a
fragment.
In
Type="http://www.w3.org/2010/xmldsig2#binary"
and
SubType="http://www.w3.org/2010/xmldsig2#fromURI"
,
same
document
references
are
not
allowed.
In
Type="http://www.w3.org/2010/xmldsig2#binary"
and
SubType="http://www.w3.org/2010/xmldsig2#fromBase64Node"
,
same
document
references
result
in
a
subtree.
xpointer
URIs
are
not
supported.
There
is
no
comment
removal
during
URI
dereferencing.
4.4.3.12
XPaths
in
2.0
mode
The
XPath
mentioned
in
the
IncludedXPath
and
ExcludedXPath
are
"normal"
XPath,
i.e.
it
is
not
like
the
XPath
optional
element
containing
information
that
aids
in
XPath
Filter
transform
which
is
evaluated
as
a
binary
expression.
Instead
this
XPath
is
a
path
to
the
root
of
the
subtree
being
included
signature
verification.
It
contains
one
or
excluded.
E.g.
more
/book/chapter
dsig2:Verification
refers
to
elements
identifying
the
all
chapter
children
of
all
book
children
type(s)
of
root
node.
The
IncludedXPath
element
should
only
select
element
nodes,
whereas
the
ExcludedXPath
element
can
choose
element
or
attribute
nodes.
Again
this
is
consistent
with
the
C14N
2.0
data
model.
This
XPath
profile
is
defined
in
[
XMLDSIG-XPATH
].
verification
information
available.
Use
of
the
DigestMethod
dsig2:Verifications
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).
For
"Compatibility
Mode"
signatures,
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
"Compatibility
Mode"
Reference
Processing
Model
(section
4.4.3.2).
If
the
result
of
URI
dereference
and
application
of
transforms
validators
is
an
octet
stream,
then
no
conversion
occurs
(comments
might
be
present
optional,
even
if
the
Canonical
XML
with
Comments
was
specified
in
the
Transforms).
The
digest
algorithm
element
is
applied
to
the
data
octets
of
the
resulting
octet
stream.
present.
For
"2.0
Mode"
signatures,
the
result
of
processing
the
example,
validators
may
ignore
a
Reference
dsig2:Verification
is
an
octet
stream,
and
the
digest
algorithm
is
applied
to
the
resulting
data
octets.
Schema Definition:
4.4.3.14
The
element
of
DigestValue
Type
Element
DigestValue
is
an
element
that
contains
"http://www.w3.org/2010/xmldsig2#PositionAssertion"
,
and
rely
on
ID-based
referencing
(with
the
encoded
value
risk
of
the
digest.
The
digest
is
always
encoded
using
base64
[
RFC2045
].
being
vulnerable
to
signature
wrapping
attacks
unless
other
steps
are
taken)
for
simplicity.
Schema Definition: <xs:element name="Verifications" type="dsig2:VerificationsType"/> <xs:complexType name="VerificationsType"> <xs:sequence> <xs:element ref="dsig2:Verification" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:element name="Verification" type="dsig2:VerificationType"/> <xs:complexType name="VerificationType"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:any namespace="##other" processContents="lax"/> <xs:element ref="dsig2:QualifiedAttr"/> <xs:element ref="dsig2:UnqualifiedAttr"/> <xs:/choice> <xs:attribute name="Type" type="xs:anyURI" use="required"/> <xs:attribute name="DigestDataLength" type="xs:nonNegativeInteger"/> <xs:attribute name="PositionAssertion" type="xs:string"/> <xs:anyAttribute namespace="##other" processContents="lax"/> <xs:/complexType>
KeyInfo
Element
KeyInfo
is
an
optional
element
that
enables
the
recipient(s)
to
obtain
the
key
needed
to
validate
the
signature.
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
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
7.2
The
KeyValue
Element
(section
4.5.2)
)
and
should
implement
RetrievalMethod
(section
4.5.3).
(
section
7.3
The
RetrievalMethod
Element
).
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 --> <!-- <element ref="dsig11:KeyInfoReference"/> --> <!-- KeyInfoReference (XMLDsig 1.1) will use the any element --> <!-- <element ref="xenc:EncryptedKey"/> --> <!-- EncryptedKey (XMLEnc) will use the any element --> <!-- <element ref="xenc:Agreement"/> --> <!-- Agreement (XMLEnc) 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>
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"/>
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
section
10.3
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>
DSAKeyValue
Element
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
Q
G
Y
J
seed
pgenCounter
Parameter
J
is
available
for
inclusion
solely
for
efficiency
as
it
is
calculatable
can
be
calculated
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>
RSAKeyValue
Element
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>
ECKeyValue
dsig11:ECKeyValue
Element
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
dsig11:ECKeyValue
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.
dsig11: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
content
to
preserve
printed
page
width.
PublicKey
dsig11:PublicKey
Domain
parameters
can
be
encoded
explicitly
using
the
ECParameters
dsig11:ECParameters
element
or
by
reference
using
the
NamedCurve
element.
dsig11:NamedCurve
element.
A
named
curve
is
specified
through
the
URI
attribute.
For
named
curves
that
are
identified
by
OIDs,
such
as
those
defined
in
[
RFC3279
][
RFC4055
],
]
and
[
SECG1
RFC4055
],
the
OID
should
be
encoded
according
to
[
URN-OID
].
Conformant
applications
must
support
the
NamedCurve
dsig11:NamedCurve
element
and
the
256-bit
prime
field
curve
as
identified
by
the
OID
1.2.840.10045.3.1.7
.
The
PublicKey
dsig11:PublicKey
element
contains
a
Base64
the
base64
encoding
of
a
binary
representation
of
the
x
and
y
coordinates
of
the
point.
point.
Its
value
is
computed
as
follows:
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>
The
ECParameters
dsig11:ECParameters
element
consists
of
the
following
subelements.
Note
these
definitions
are
based
on
the
those
described
in
[
RFC3279
].
dsig11: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.
dsig11: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
dsig11:Base
element
specifies
the
base
point
P
on
the
elliptic
curve.
The
base
point
is
represented
as
a
value
of
type
dsig11:ECPointType
.
dsig11:Order
element
specifies
the
order
n
of
the
base
point
and
is
encoded
as
a
positiveInteger
.
dsig11: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.
dsig11: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.
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
dsig11:Prime
fields
are
described
by
a
single
subelement
P,
dsig11:P
,
which
represents
the
field
size
in
bits.
It
is
encoded
as
a
positiveInteger.
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>
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:
ECDSAKeyValue
element
against
the
[
RFC4050
]
schema.
XML
NamedCurve
element.
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.
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
section
B.4
The
URI
Attribute
in
"Compatibility
Mode"
(section
4.4.3.1)
and
section
B.4.1
The
"Compatibility
Mode"
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
7.
The
KeyInfo
Element
(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.
Transforms
in
RetrievalMethod
are
more
attack
prone,
since
they
need
to
be
evaluated
in
the
first
step
of
the
SignatureValidation,
signature
validation,
where
the
trust
in
the
key
has
not
yet
been
established,
and
the
SignedInfo
has
not
yet
been
verified.
As
noted
in
the
[
XMLDSIG-BESTPRACTICES
]
an
attacker
can
easily
causes
a
Denial
of
service,
by
adding
a
specially
crafted
transform
in
the
RetrievalMethod
without
even
bothering
to
have
the
key
validate
or
the
signature
match.
In
2.0
Mode,
XML
Signature
2.0,
Transforms
are
not
allowed
in
RetrievalMethod
.
Use
of
is
encouraged
instead,
see
section
KeyInfoReference
dsig11:KeyInfoReference
4.5.10.
7.10
The
dsig11:KeyInfoReference
Element
.
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.
X509Data
Element
Type="
http://www.w3.org/2000/09/xmldsig#X509Data
"
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
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:
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,
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,
X509SKI
element,
which
contains
the
base64
encoded
plain
(i.e.
non-DER-encoded)
value
of
a
X509
V.3
SubjectKeyIdentifier
extension,
X509Certificate
element,
which
contains
a
base64-encoded
[
X509V3
]
certificate,
and
X509CRL
element,
which
contains
a
base64-encoded
certificate
revocation
list
(CRL)
[
X509V3
].
dsig11:X509Digest
element
contains
a
base64-encoded
digest
of
a
certificate.
The
digest
algorithm
URI
is
identified
with
a
required
Algorithm
attribute.
The
input
to
the
digest
must
be
the
raw
octets
that
would
be
base64-encoded
were
the
same
certificate
to
appear
in
the
X509Certificate
element.
dsig11:OCSPResponse
element
contains
a
base64-encoded
OCSP
response
in
DER
encoding.
[
OCSP
].
Any
X509IssuerSerial
,
X509SKI
,
and
X509SubjectName
,
and
dsig11:X509Digest
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
,
and
dsig11:X509Digest
elements
that
relate
to
the
same
key
but
different
certificates
must
be
grouped
within
a
single
KeyInfo
but
may
occur
in
multiple
X509Data
elements.
Note
that
if
X509Data
child
elements
are
used
to
identify
a
trusted
certificate
(rather
than
solely
as
an
untrusted
hint
supplemented
by
validation
by
policy),
the
complete
set
of
such
elements
that
are
intended
to
identify
a
certificate
should
be
integrity
protected,
typically
by
signing
an
entire
X509Data
or
KeyInfo
element.
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.
XML
Schema
validators
may
not
support
integer
types
with
decimal
data
exceeding
18
decimal
digits
[XML-schema].
Therefore
such
deployments
should
avoid
schema-validating
the
X509IssuerSerial
element,
or
make
use
of
a
local
copy
of
the
schema
that
adjusts
the
data
type
of
the
X509SerialNumber
child
element
from
"integer"
to
"string"
.
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:
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"/> -->
<!-- <element ref="dsig11:X509Digest"/> -->
<!-- OCSPResponse and X509Digest 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 section 7. The KeyInfo Element 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" /> <element name="X509Digest" type="dsig11:X509DigestType"/> <complexType name="X509DigestType"> <simpleContent> <extension base="base64Binary"> <attribute name="Algorithm" type="anyURI" use="required"/> </extension> </simpleContent> </complexType>
PGPData
Element
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>
SPKIData
Element
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>
MgmtData
Element
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)
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.
KeyInfo
types
for
conveying
key
information.
Schema Definition: <element name="MgmtData" type="string"/>
EncryptedKey
and
DerivedKey
Elements
<xenc:EncryptedKey>
and
<xenc:DerivedKey>
elements
defined
in
[
XMLENC-CORE1
]
as
children
of
ds:KeyInfo
can
be
used
to
convey
in-band
encrypted
or
derived
key
material.
In
particular,
the
xenc:DerivedKey
>
element
may
be
present
when
the
key
used
in
calculating
a
Message
Authentication
Code
is
derived
from
a
shared
secret.
DEREncodedKeyValue
dsig11:DEREncodedKeyValue
Element
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:
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
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
DEREncodedKeyValue
dsig11:DEREncodedKeyValue
Section
4.5.2
section
7.2
The
KeyValue
Element
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
element
is
not
a
child
of
DEREncodedKeyValue
dsig11:DEREncodedKeyValue
KeyValue
.
The
element
is
also
not
a
child
of
the
DEREncodedKeyValue
dsig11:DEREncodedKeyValue
X509Data
element,
as
the
keys
represented
by
may
not
have
X.509
certificates
associated
with
them
(a
requirement
for
DEREncodedKeyValue
dsig11:DEREncodedKeyValue
X509Data
).
KeyInfoReference
dsig11:KeyInfoReference
Element
A
element
within
KeyInfoReference
dsig11:KeyInfoReference
KeyInfo
is
used
to
convey
a
reference
to
a
KeyInfo
element
at
another
location
in
the
same
or
different
document.
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
element
instead
of
including
the
entire
chain
with
a
sequence
of
KeyInfoReference
dsig11:KeyInfoReference
X509Certificate
elements
repeated
in
multiple
places.
uses
the
same
syntax
and
dereferencing
behavior
as
KeyInfoReference
dsig11:KeyInfoReference
Reference
's
URI
(section
4.4.3.1)
(
section
B.4
The
URI
Attribute
in
"Compatibility
Mode"
)
and
the
Reference
Processing
Model
(section
4.4.3.2)
(
section
B.4.1
The
"Compatibility
Mode"
Reference
Processing
Model
)
except
that
there
are
no
child
elements
and
the
presence
of
the
URI
attribute
is
mandatory.
The
result
of
dereferencing
a
must
be
a
KeyInfoReference
dsig11:KeyInfoReference
KeyInfo
element,
or
an
XML
document
with
a
KeyInfo
element
as
the
root.
Note:
The
element
is
a
desirable
alternative
to
the
use
of
KeyInfoReference
dsig11:KeyInfoReference
RetrievalMethod
when
the
data
being
referred
to
is
a
KeyInfo
element
and
the
use
of
RetrievalMethod
would
require
one
or
more
Transform
child
elements,
which
introduce
security
risk
and
implementation
challenges.
challenges,
and
are
precluded
when
using
XML
Signature
2.0
signatures.
Schema Definition <!-- targetNamespace="http://www.w3.org/2009/xmldsig11#" --> <element name="KeyInfoReference" type="dsig11:KeyInfoReferenceType"/> <complexType name="KeyInfoReferenceType"> <attribute name="URI" type="anyURI" use="required"/> <attribute name="Id" type="ID" use="optional"/> </complexType>
Object
Element
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
that
require
normative
type
and
encoding
information
for
signature
validation
should
specify
the
Type
and
possibly
rely
on
in
the
SubType
Algorithm
element
("2.0
Selection
dsig2:Selection
mode")
Mode")
or
specify
Transforms
with
well
defined
resulting
types
and/or
encodings
("compatibility
mode").
("Compatibility
Mode").
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
using
standard
Referencing
mechanisms.
E.g.
e.g.
<Object>
tag,
then
use
an
XPath
Transform
IncludedXPath
dsig2:IncludedXPath
dsig2:Selection
with
a
Subtype="http://www.w3.org/2010/xmldsig2#fromBase64Node"
Algorithm="http://www.w3.org/2010/xmldsig2#binaryfromBase64"
Transform
(compatibility
mode)
("Compatibility
Mode")
or
dsig2:Selection
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:
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>
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
.
Manifest
Element
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
Reference
s.
The
difference
from
the
list
in
SignedInfo
is
that
it
is
application
defined
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>
SignatureProperties
Element
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"/> <!-- (1,1) elements from (1,unbounded) namespaces --> </choice> <attribute name="Target" type="anyURI" use="required"/> <attribute name="Id" type="ID" use="optional"/> </complexType>
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
CanonicalizationMethod
s
canonicalization
algorithms
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.
XML comments are not used by this specification.
Note
that
unless
the
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.
This specification defines several possible digest algorithms for the DigestMethod element, including required algorithm SHA-256. Use of SHA-256 is strongly recommended over SHA-1 because recent advances in cryptanalysis (see e.g. [ SHA-1-Analysis ]) have cast doubt on the long-term collision resistance of SHA-1. Therefore, SHA-1 support is required in this specification only for backwards-compatibility reasons.
Digest algorithms that are known not to be collision resistant should not be used in DigestMethod elements. For example, the MD5 message digest algorithm should not be used as specific collisions have been demonstrated for that algorithm.
The SHA-1 algorithm [ FIPS-186-3 ] 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 20-octet octet stream. For example, the DigestValue element for the message digest:
A9993E36 4706816A BA3E2571 7850C26C 9CD0D89D
from Appendix A of the SHA-1 standard would be:
<DigestValue> qZk+NkcGgWq6PiVxeFDCbJzQ2J0= </DigestValue>
The SHA-256 algorithm [ FIPS-180-3 ] takes no explicit parameters. A SHA-256 digest is a 256-bit string. The content of the DigestValue element shall be the base64 encoding of this bit string viewed as a 32-octet octet stream.
The SHA-384 algorithm [ FIPS-180-3 ] takes no explicit parameters. A SHA-384 digest is a 384-bit string. The content of the DigestValue element shall be the base64 encoding of this bit string viewed as a 48-octet octet stream.
The SHA-512 algorithm [ FIPS-180-3 ] takes no explicit parameters. A SHA-512 digest is a 512-bit string. The content of the DigestValue element shall be the base64 encoding of this bit string viewed as a 64-octet octet stream.
MAC
algorithms
take
two
implicit
parameters,
their
keying
material
determined
from
KeyInfo
and
the
octet
stream
output
by
CanonicalizationMethod
.
MACs
and
signature
algorithms
are
syntactically
identical
but
a
MAC
implies
a
shared
secret
key.
The
HMAC
algorithm
(RFC2104
[
HMAC
])
takes
the
output
(truncation)
length
in
bits
as
a
parameter;
this
specification
REQUIRES
that
the
truncation
length
be
a
multiple
of
8
(i.e.
fall
on
a
byte
boundary)
because
Base64
encoding
operates
on
full
bytes.
bytes.
If
the
truncation
parameter
is
not
specified
then
all
the
bits
of
the
hash
are
output.
Any
signature
with
a
truncation
length
that
is
less
than
half
the
output
length
of
the
underlying
hash
algorithm
must
be
deemed
invalid.
An
example
of
an
HMAC
SignatureMethod
element:
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#hmac-sha1"> <HMACOutputLength>128</HMACOutputLength> </SignatureMethod>
The
output
of
the
HMAC
algorithm
is
ultimately
the
output
(possibly
truncated)
of
the
chosen
digest
algorithm.
This
value
shall
be
base64
encoded
in
the
same
straightforward
fashion
as
the
output
of
the
digest
algorithms.
Example:
the
SignatureValue
element
for
the
HMAC-SHA1
digest
9294727A 3638BB1C 13F48EF8 158BFC9D
from the test vectors in [ HMAC ] would be
<SignatureValue> kpRyejY4uxwT9I74FYv8nQ== </SignatureValue>
Schema Definition: <simpleType name="HMACOutputLengthType"> <restriction base="integer"/> </simpleType>
Signature
algorithms
take
two
implicit
parameters,
their
keying
material
determined
from
KeyInfo
and
the
octet
stream
output
by
CanonicalizationMethod
.
Signature
and
MAC
algorithms
are
syntactically
identical
but
a
signature
implies
public
key
cryptography.
The
DSA
family
of
algorithms
is
defined
in
FIPS
186-3
[
FIPS-186-3
].
].
FIPS
186-3
defines
DSA
in
terms
of
two
security
parameters
L
and
N
where
L
=
|p|,
N
=
|q|,
p
is
the
prime
modulus,
q
is
a
prime
divisor
of
(p-1).
(p-1).
FIPS
186-3
defines
four
valid
pairs
of
(L,
N);
they
are:
(1024,
160),
(2048,
224),
(2048,
256)
and
(3072,
256).
256).
The
pair
(1024,
160)
corresponds
to
the
algorithm
DSAwithSHA1,
which
is
identified
in
this
specification
by
the
URI
http://www.w3.org/2000/09/xmldsig#dsa-sha1
.
.
The
pairs
(2048,
256)
and
(3072,
256)
correspond
to
the
algorithm
DSAwithSHA256,
which
is
identified
in
this
specification
by
the
URI
http://www.w3.org/2009/xmldsig11#dsa-sha256
.
.
This
specification
does
not
use
the
(2048,
224)
instance
of
DSA
(which
corresponds
to
DSAwithSHA224).
DSA
DSA
takes
no
explicit
parameters;
an
example
of
a
DSA
SignatureMethod
element
is:
<SignatureMethod Algorithm="http://www.w3.org/2009/xmldsig11#dsa-sha256"/>
The
output
of
the
DSA
algorithm
consists
of
a
pair
of
integers
usually
referred
by
the
pair
(r,
s).
The
signature
value
consists
of
the
base64
encoding
of
the
concatenation
of
two
octet-streams
that
respectively
result
from
the
octet-encoding
of
the
values
r
and
s
in
that
order.
Integer
to
octet-stream
conversion
must
be
done
according
to
the
I2OSP
operation
defined
in
the
RFC
3447
[
PKCS1
]
specification
with
a
l
parameter
equal
to
20.
For
example,
the
SignatureValue
element
for
a
DSA
signature
(
r
,
s
)
with
values
specified
in
hexadecimal:
r = 8BAC1AB6 6410435C B7181F95 B16AB97C 92B341C0
s = 41E2345F 1F56DF24 58F426D1 55B4BA2D B6DCD8C8
from the example in Appendix 5 of the DSS standard would be
<SignatureValue>
i6watmQQQ1y3GB+VsWq5fJKzQcBB4jRfH1bfJFj0JtFVtLotttzYyA== </SignatureValue>
Per FIPS 186-3 [ FIPS-186-3 ], the DSA security parameter L is defined to be 1024, 2048 or 3072 bits and the corresponding DSA q value is defined to be 160, 224/256 and 256 bits respectively. Special Publication SP 800-57 Part 1 [ SP800-57 ], NIST recommends using at least at 2048-bit public keys for securing information beyond 2010 (and 3072-bit keys for securing information beyond 2030).
Since XML Signature 1.0 requires implementations to support DSA-based digital signatures, this XML Signature 1.1 revision REQUIRES signature verifiers to implement DSA only for keys of 1024 bits in order to guarantee interoperability with XML Signature 1.0 generators. XML Signature 1.1 implementations may but are not required to support DSA-based signature generation, and given the short key size and the SP800-57 guidelines, DSA with 1024-bit prime moduli should not be used for signatures that will be verified beyond 2010.
The expression "RSA algorithm" as used in this specification refers to the RSASSA-PKCS1-v1_5 algorithm described in RFC 3447 [ PKCS1 ]. The RSA algorithm takes no explicit parameters. An example of an RSA SignatureMethod element is:
<SignatureMethod
Algorithm
=
"http://www.w3.org/2000/09/xmldsig#rsa-sha1"
/>
The
SignatureValue
content
for
an
RSA
signature
is
the
base64
[
RFC2045
]
encoding
of
the
octet
string
computed
as
per
RFC
3447
[
PKCS1
],
section
8.2.1:
Signature
generation
for
the
RSASSA-PKCS1-v1_5
signature
scheme].
Computation
of
the
signature
will
require
concatenation
of
the
hash
value
and
a
constant
string
determined
by
RFC
3447.
Signature
computation
and
verification
does
not
require
implementation
of
an
ASN.1
parser.
The resulting base64 [ RFC2045 ] string is the value of the child text node of the SignatureValue element, e.g.
<SignatureValue> IWijxQjUrcXBYoCei4QxjWo9Kg8D3p9tlWoT4t0/gyTE96639In0FZFY2/rvP+/bMJ01EArmKZsR5VW3rwoPxw= </SignatureValue>
The
ECDSA
algorithm
[
FIPS-186-3
]
takes
no
explicit
parameters.
An
example
of
a
ECDSA
SignatureMethod
element
is:
<SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"/>
The
output
of
the
ECDSA
algorithm
consists
of
a
pair
of
integers
usually
referred
by
the
pair
(r,
s).
The
signature
value
consists
of
the
base64
encoding
of
the
concatenation
of
two
octet-streams
that
respectively
result
from
the
octet-encoding
of
the
values
r
and
s
in
that
order.
Integer
to
octet-stream
conversion
must
be
done
according
to
the
I2OSP
operation
defined
in
the
RFC
3447
[
PKCS1
]
specification
with
the
l
parameter
equal
to
the
size
of
the
base
point
order
of
the
curve
in
bytes
(e.g.
32
for
the
P-256
curve
and
66
for
the
P-521
curve).
This specification REQUIRES implementations to support the ECDSAwithSHA256 signature algorithm, which is ECDSA over the P-256 prime curve specified in Section D.2.3 of FIPS 186-3 [ FIPS-186-3 ] (and using the SHA-256 hash algorithm). It is further recommended that implementations also support ECDSA over the P-384 and P-521 prime curves; these curves are defined in Sections D.2.4 and D.2.5 of FIPS 186-3, respectively.
All
2.0
mode
signatures
must
use
Canonicalization
algorithms
designated
as
The
input
to
any
canonicalization
algorithm
compatible
with
XML
Signature
2.0
mode.
Section
"2.0
Mode"
Canonicalization
Algorithms
lists
such
compatible
algorithms
as
of
publication.
If
canonicalization
signatures
is
performed
over
octets,
the
canonicalization
algorithms
take
two
implicit
parameters:
the
content
a
set
of
document
subtrees
and
its
charset.
The
charset
is
derived
according
to
exclusions
in
the
rules
form
of
subtrees
or
XML
attributes.
The
actual
representation
of
these
inputs
depends
on
the
transport
protocols
processing
model
and
media
types
(e.g,
[
XML-MEDIA-TYPES
]
defines
the
media
types
may
be
in
terms
of
DOM
nodes
or
representations
suitable
for
XML).
This
information
streaming-based
processing.
The
output
is
necessary
to
correctly
sign
and
verify
documents
and
often
requires
careful
server
side
configuration.
an
octet
stream.
Various
canonicalization
algorithms
require
conversion
to
[
UTF-8
].
Note:
The
algorithms
below
understand
at
least
[
UTF-8
]
and
[
UTF-16
]
as
input
encodings.
We
RECOMMEND
that
externally
specified
algorithms
do
the
same.
Knowledge
of
other
encodings
is
optional
.
Various
canonicalization
algorithms
transcode
from
a
non-Unicode
encoding
passed
to
Unicode.
The
output
of
these
"2.0
Mode"
canonicalization
algorithms
will
be
in
NFC
[
NFC
].
This
is
because
must
always
exclude
the
XML
processor
used
to
prepare
current
Signature
element
node
(i.e.,
the
XPath
data
model
input
is
required
(by
Signature
must
be
passed
as
one
of
the
Data
Model)
exclusion
elements.
This
is
equivalent
to
use
Normalization
Form
C
when
converting
an
XML
document
to
the
UCS
character
domain
from
any
encoding
that
is
not
UCS-based.
We
RECOMMEND
that
externally
specified
canonicalization
algorithms
do
the
same.
(Note,
there
can
be
ambiguities
implicit
Enveloped
Signature
Transform
in
converting
existing
charsets
to
Unicode,
"Compatibility
Mode",
and
has
no
effect
for
an
example
see
the
XML
Japanese
Profile
Note
[
XML-Japanese
].)
non-enveloped
signatures.
This
specification
REQUIRES
implementation
of
Canonical
XML
1.0
[
XML-C14N
],
Canonical
XML
1.1
[
XML-C14N11
]]
and
Exclusive
XML
Canonicalization
2.0
[
XML-EXC-C14N
XML-C14N20
].
We
RECOMMEND
that
applications
that
generate
signatures
choose
Canonical
XML
1.1
[
XML-C14N11
]
when
inclusive
Applications
may
support
other
canonicalization
is
desired.
Note
:
Canonical
XML
1.0
[
XML-C14N
]
and
Canonical
XML
1.1
[
XML-C14N11
]
specify
a
standard
serialization
of
XML
that,
when
applied
to
a
subdocument,
includes
the
subdocument's
ancestor
context
including
all
of
the
namespace
declarations
and
some
attributes
in
algorithms
with
the
'xml:'
namespace.
However,
some
applications
require
a
method
which,
same
input
model
(subtrees
with
exclusions).
A
Reference
to
the
extent
practical,
excludes
unused
ancestor
context
from
a
canonicalized
subdocument.
The
Exclusive
XML
Canonicalization
Recommendation
[
XML-EXC-C14N
]
non-XML
data
may
be
used
to
address
requirements
resulting
from
scenarios
where
not
use
canonicalization
at
all,
or
may
use
a
subdocument
is
moved
between
contexts.
custom
canonicalization
algorithm
with
this
input
model
or
a
completely
different
one.
An
example
of
an
a
Canonical
XML
canonicalization
2.0
element
is:
<CanonicalizationMethod Algorithm="http://www.w3.org/2010/xml-c14n2"
xmlns:c14n2="http://www.w3.org/2010/xml-c14n2">
<c14n2:PrefixRewrite>sequential</c14n2:PrefixRewrite>
<c14n2:TrimTextNodes>true</c14n2:TrimTextNodes>
<c14n2:QNameAware>
<c14n2:QualifiedAttr Name="type" NS="http://www.w3.org/2001/XMLSchema-instance"/>
</c14n2:QNameAware>
</CanonicalizationMethod>
The
normative
specification
of
Canonical
XML1.0
is
[
XML-C14N
].
The
algorithm
There
is
capable
of
taking
as
input
either
an
octet
stream
or
an
XPath
node-set
(or
sufficiently
functional
alternative).
The
algorithm
produces
an
octet
stream
as
output.
no
Canonical
XML
2.0
Transform
.
Instead
the
same
CanonicalizationMethod
element
is
easily
parameterized
(via
an
additional
URI)
to
omit
or
retain
comments.
6.5.2
Canonical
XML
1.1
Identifier
for
required
Canonical
XML
1.1
(omits
comments):
http://www.w3.org/2006/12/xml-c14n11
Identifier
reused
within
the
dsig2:Selection
element
for
Canonical
XML
1.1
with
Comments:
http://www.w3.org/2006/12/xml-c14n11#WithComments
Input:
octet-stream,
node-set
Output:
octet-stream
specifying
canonicalization
of
referenced
data,
The
normative
specification
of
Canonical
XML
1.1
2.0
is
[
XML-C14N11
XML-C14N20
].
The
algorithm
is
capable
of
taking
as
input
either
an
octet
stream
or
an
XPath
node-set
(or
sufficiently
functional
alternative).
The
algorithm
produces
an
octet
stream
as
output.
Canonical
XML
1.1
is
easily
parameterized
(via
an
additional
URI)
to
omit
or
retain
comments.
6.5.3
Exclusive
XML
Canonicalization
1.0
Identifier
for
Exclusive
XML
Canonicalization
1.0
(omits
comments):
http://www.w3.org/2001/10/xml-exc-c14n#
Identifier
for
Exclusive
XML
Canonicalization
1.0
with
Comments:
http://www.w3.org/2001/10/xml-exc-c14n#WithComments
Input:
octet-stream,
node-set
Output:
octet-stream
The
normative
specification
of
Exclusive
XML
Canonicalization
1.0
is
[XML-EXC-C14N]].
Transform
2.0
mode
signatures
do
not
use
these
Transform
algorithms.
See
section.
A
In
XML
Signature
2.0,
the
Transforms
element
contains
exactly
one
Transform
algorithm
has
a
single
implicit
parameter:
element
with
an
octet
stream
from
the
Reference
Algorithm
or
the
output
of
an
earlier
.
Transform
"http://www.w3.org/2010/xmldsig2#transform"
For
implementation
requirements,
please
see
Algorithm
Identifiers
and
Implementation
Requirements
.
Application
developers
are
strongly
encouraged
This
transform
encapsulates
the
process
of
selecting
the
content
to
support
all
transforms
sign,
canonicalizing
it,
and
attaching
optional
material
that
are
listed
as
recommended
unless
may
aid
the
application
environment
has
resource
constraints
that
would
make
such
support
impractical.
Compliance
with
this
recommendation
will
maximize
application
interoperability
and
libraries
should
be
available
to
enable
support
of
these
transforms
in
applications
without
extensive
development.
verifier.
Any
canonicalization
algorithm
that
can
be
used
for
This
fixed
CanonicalizationMethod
Transform
(such
as
those
in
Canonicalization
Algorithms
(section
6.5))
can
be
used
as
element
consists
of
a
single
required
element,
followed
by
an
optional
Transform
.
dsig2:Selection
CanonicalizationMethod
element,
and
an
optional
dsig2:Verifications
element.
dsig2:Selection
Algorithms
The
normative
specification
for
base64
decoding
transforms
is
[
RFC2045
].
The
base64
This
Transform
dsig2:Selection
element
has
no
content.
The
input
is
decoded
by
the
algorithms.
This
transform
is
useful
if
an
application
needs
to
sign
the
raw
data
associated
with
algorithm
allows
the
encoded
content
selection
of
an
element.
XML
documents
or
fragments.
This
transform
accepts
either
The
required
URI
attribute
can
be
an
octet-stream
external
or
a
node-set
as
input.
If
an
octet-string
is
given
as
input,
then
this
octet-stream
is
processed
directly.
If
an
XPath
node-set
(or
sufficiently
functional
alternative)
is
given
as
input,
then
it
is
converted
to
same-document
reference.
External
references
are
parsed
into
an
octet
XML
document
or
event
stream
by
performing
operations
logically
equivalent
for
the
subsequent
selection
process
to
1)
applying
operate
upon.
self::text()
,
then
2)
taking
URI=""
)
or
a
fragment
(e.g
URI="#foo"
).
The
former
refers
to
the
Reference
URI="http://example.com/bar.xml"
URI="http://example.com/bar.xml#chapter1"
).
The
differences
between
the
identified
element
processing,
and
any
allowed
syntax,
of
its
descendant
elements
as
well
as
any
descendant
comments
this
URI
attribute
and
processing
instructions.
The
output
that
of
this
transform
is
an
octet
stream.
a
"Compatibility
Mode"
Reference
URI
are:
xpointer
syntax
is
The
XPath
expression
to
dsig2:IncludedXPath
must
not
be
evaluated
appears
as
present,
if
the
character
content
of
a
transform
parameter
child
element
named
contains
a
fragment
identifier.
The
XPath
.
URI
input
required
by
this
transform
is
an
XPath
node-set
or
an
octet-stream.
Note
that
dsig2:ExcludedXPath
maybe
present
even
if
the
actual
input
there
is
an
XPath
node-set
resulting
from
a
null
URI
or
shortname
XPointer
dereference,
then
comment
nodes
will
have
been
omitted.
If
the
actual
input
is
an
octet
stream,
then
fragment
identifier.
I.e
the
application
dsig2:Selection
must
convert
the
octet
stream
to
an
XPath
node-set
suitable
for
use
by
Canonical
XML
with
Comments.
(A
subsequent
application
of
the
required
Canonical
XML
algorithm
would
strip
away
these
comments.)
In
other
words,
the
input
node-set
should
be
equivalent
to
the
have
one
that
would
be
created
by
of
the
following
process:
URI
attribute
with
or
without
a
fragment
identifier.
URI
attribute
with
or
without
a
fragment
identifier,
and
dsig2:ExcludedXPath
parameter
element.
(//.
|
//@*
|
//namespace::*)
URI
attribute
and
one
dsig2:IncludedXPath
parameter
element.
XPath
URI
attribute,
one
dsig2:IncludedXPath
parameter
dsig2:ExcludedXPath
parameter
element.
Note:
Even
if
the
input
node-set
has
had
comments
removed,
the
comment
nodes
still
exist
in
the
underlying
parse
tree
and
can
separate
text
nodes.
For
example,
the
markup
When
an
<e>Hello,
<!--
comment
-->world!</e>
IncludedXPath
contains
two
text
nodes.
Therefore,
the
expression
or
self::text()[string()="Hello,
world!"]
ExcludedXPath
would
fail.
Should
this
problem
arise
in
the
application,
selects
an
element
node,
it
can
be
solved
by
either
canonicalizing
the
document
before
the
XPath
transform
to
physically
remove
implies
that
the
comments
whole
subtree
rooted
at
that
element
is
included
or
by
matching
the
node
based
on
the
parent
element's
string
value
(e.g.
by
using
the
expression
self::text()[string(parent::e)="Hello,
world!"]
).
excluded.
The
primary
purpose
Processing
of
this
transform
is
to
ensure
that
only
specifically
defined
changes
to
the
input
XML
document
are
permitted
after
the
signature
is
affixed.
This
is
done
by
omitting
precisely
those
nodes
that
are
allowed
to
change
once
the
signature
is
affixed,
selection
and
including
all
other
input
nodes
in
the
output.
It
parameters
is
as
follows:
IncludedXPath
element
is
present,
evaluate
this
XPath
dsig2:ExcludedXPath
is
present,
evaluate
it
at
the
root
of
the
document
to
Signature
element
under
computation/evaluation
to
the
The
result
of
variable
bindings.
No
means
for
initializing
these
is
defined.
Thus,
the
selection
process
is
a
set
of
variable
bindings
used
when
evaluating
the
XPath
expression
is
empty,
one
or
more
element
nodes,
and
use
of
a
variable
reference
in
the
XPath
expression
results
in
an
error.
The
set
of
namespace
declarations
in
scope
for
the
XPath
expression.
zero
or
more
exclusions
consisting
of
element
and/or
attribute
nodes.
As
Note:
In
a
result
"streaming
mode"
of
the
context
node
setting,
evaluation,
the
XPath
expressions
appearing
in
this
transform
will
be
quite
similar
evaluation,
the
canonicalizaion
and
digesting
need
to
those
used
happen
in
used
a
pipeline.
This
is
described
in
Section
"2.1
Streaming
for
XPath
Signatures"
in
[
XSLT
XMLDSIG-XPATH
],
except
that
the
size
and
position
are
always
1
to
reflect
the
fact
that
the
transform
is
automatically
visiting
every
node
(in
XSLT,
one
recursively
calls
the
command
apply-templates
to
visit
the
nodes
of
the
input
tree).
].
here()
dsig2:IncludedXPath
The
here
function
returns
a
node-set
containing
the
attribute
or
processing
instruction
node
or
the
parent
dsig2:IncludedXPath
element
of
the
text
node
that
directly
bears
is
used
in
conjunction
with
XML-based
dsig2:Selection
algorithms
to
specify
the
XPath
expression.
This
expression
results
subtree(s)
to
include
in
a
selection.
The
element
contains
an
error
if
the
containing
XPath
1.0
expression
does
not
appear
that
is
evaluated
in
the
same
XML
document
against
which
context
of
the
XPath
expression
is
being
evaluated.
root
of
the
XML
document.
As
an
For
example,
consider
creating
an
enveloped
signature
(a
Signature
"/Book/Chapter"
element
that
is
a
descendant
of
an
element
being
signed).
Although
the
signed
content
should
not
be
changed
after
signing,
refers
to
the
subtrees
rooted
by
all
Chapter
child
elements
within
the
of
all
Signature
Book
element
are
changing
(e.g.
child
elements
of
the
digest
value
document
root.
The
XPath
1.0
expression
must
be
put
inside
the
DigestValue
evaluate
only
to
element
nodes,
and
the
SignatureValue
must
be
subsequently
calculated).
One
way
conform
to
prevent
these
changes
from
invalidating
the
digest
value
in
DigestValue
is
XML
Signature
Streaming
Profile
of
XPath
1.0
[
XMLDSIG-XPATH
].
Implementations
are
not
required
to
add
an
use
a
streaming
XPath
Transform
processor,
but
the
expressions
used
must
conform
to
the
streaming
profile
to
ensure
compatibility
with
implementations
that
omits
all
Signature
elements
and
their
descendants.
For
example,
do
use
a
streaming
processor.
Schema Definition: <xs:element name="IncludedXPath" type="xs:string"/>
dsig2:ExcludedXPath
Element
Due
to
the
null
The
Reference
dsig2:ExcludedXPath
URI
in
this
example,
the
XPath
transform
input
node-set
contains
all
nodes
in
the
entire
parse
tree
starting
at
the
root
node
(except
the
comment
nodes).
For
each
node
in
this
node-set,
the
node
element
is
included
used
in
the
output
node-set
except
if
the
node
or
one
of
its
ancestors
has
a
tag
of
conjunction
with
XML-based
algorithms
to
specify
subtree(s)
and/or
attributes
to
exclude
from
a
selection.
The
element
contains
an
XPath
1.0
expression
that
is
evaluated
in
the
Signature
dsig2:Selection
namespace
given
by
context
of
the
replacement
text
for
root
of
the
entity
&dsig;
.
XML
document.
A
more
elegant
solution
uses
the
here
function
to
omit
only
the
For
example,
Signature
"/Book/Chapter"
containing
the
XPath
Transform,
thus
allowing
enveloped
signatures
refers
to
sign
other
signatures.
In
the
example
above,
use
the
subtrees
rooted
by
all
XPath
Chapter
element:
child
elements
of
all
Book
child
elements
of
the
document
root.
Since
the
The
XPath
equality
operator
converts
node
sets
1.0
expression
must
evaluate
to
string
values
before
comparison,
we
element
and/or
attribute
nodes,
and
must
instead
use
conform
to
the
XPath
union
operator
(|).
For
each
node
XML
Signature
Streaming
Profile
of
XPath
1.0
[
XMLDSIG-XPATH
].
Implementations
are
not
required
to
use
a
streaming
XPath
processor,
but
the
document,
the
predicate
expression
is
true
if
and
only
if
the
node-set
containing
expressions
used
must
conform
to
the
node
and
its
streaming
profile
to
ensure
compatibility
with
implementations
that
do
use
a
streaming
processor.
Schema Definition: <xs:element name="ExcludedXPath" type="xs:string"/>
Signature
dsig2:ByteRange
The
element
Signature
dsig2:ByteRange
containing
the
XPath
expression
(the
union
does
not
produce
a
larger
set
if
the
enveloped
is
used
in
conjunction
with
binary
algorithms
to
specify
byte
range
subsets
of
the
originally
selected
octet
stream
to
include.
Signature
dsig2:Selection
The
element
is
in
value
must
conform
to
the
node-set
given
by
Byte
Ranges
syntax
described
in
section
14.35.1
of
[
HTTP11
].
For
example,
element
content
of
ancestor-or-self::Signature
0-20,220-270,320-
).
indicates
that
the
first
21
bytes,
then
bytes
220
through
270,
and
finally
bytes
320
through
the
rest
of
the
stream
are
included.
Schema Definition: <xs:element name="ByteRange" type="xs:string"/>
An
enveloped
signature
transform
T
removes
the
whole
This
Signature
dsig2:Selection
element
containing
T
from
algorithm
allows
the
digest
calculation
selection
of
the
external
binary
data.
The
required
Reference
URI
element
containing
T
attribute
must
.
The
entire
string
of
characters
used
by
be
an
XML
processor
to
match
external
reference
and
the
result
of
dereferencing
it
is
treated
as
an
octet
stream.
The
Signature
dsig2:Selection
with
the
XML
production
element
may
contain
at
most
one
dsig2:ByteRange
is
removed.
The
output
of
the
transform
is
equivalent
parameter
element
to
modify
the
output
that
would
result
selection
result.
If
present,
the
range(s)
indicated
modify
the
resulting
octet
stream
obtained
from
replacing
T
with
an
XPath
transform
containing
the
following
.
The
implementation
may
incorporate
the
byte
range
into
the
dereferencing
process
as
an
optimization.
XPath
parameter
element:
URI
The
input
and
output
requirements
of
this
transform
are
identical
to
those
final
result
of
the
XPath
transform,
but
may
only
be
applied
to
a
node-set
from
its
parent
XML
document.
Note
that
it
selection
process
is
not
necessary
to
use
an
XPath
expression
evaluator
to
create
this
transform.
However,
this
transform
must
produce
output
in
exactly
the
same
manner
as
the
XPath
transform
parameterized
by
the
XPath
expression
above.
octet
stream.
The
normative
specification
for
XSL
Transformations
is
[
XSLT
].
Specification
of
a
namespace-qualified
stylesheet
element,
which
must
be
the
sole
child
of
the
This
Transform
dsig2:Selection
element,
indicates
that
algorithm
allows
the
specified
style
sheet
should
be
used.
Whether
this
instantiates
in-line
processing
selection
of
local
XSLT
declarations
base64-encoded
binary
data
from
a
Text
node
within
the
resource
is
determined
by
the
XSLT
processing
model;
the
ordered
application
of
multiple
stylesheet
may
require
multiple
an
XML
document.
The
required
attribute
can
be
Transforms
.
No
special
provision
is
made
for
the
identification
of
a
remote
stylesheet
at
a
given
URI
because
it
communicated
via
an
xsl:include
external
or
xsl:import
within
the
stylesheet
child
of
the
Transform
.
This
transform
requires
same-document
reference.
External
references
are
parsed
into
an
octet
XML
document
or
event
stream
as
input.
The
output
of
this
transform
is
an
octet
stream.
The
processing
rules
for
the
XSL
style
sheet
[
XSL10
]
or
transform
element
are
stated
in
the
XSLT
specification
[
XSLT
].
subsequent
selection
process
to
operate
upon.
xml
URI=""
URI="#foo"
).
The
former
refers
to
URI="http://example.com/bar.xml"
)
or
refer
to
fragments
of
Selection
URI="http://example.com/bar.xml#chapter1"
The
following
selection
algorithms
are
required
.
6.7.1
Selection
differences
between
the
processing,
and
allowed
syntax,
of
this
Type="http://www.w3.org/2010/xmldsig2#xml"
URI
Type
attribute
and
SubType
that
of
a
"Compatibility
Mode"
Type="http://www.w3.org/2010/xmldsig2#xml"
Reference
Parameters
URI
are:
:
See
section
URIs
for
2.0
mode
.
xpointer
syntax
is
not
permitted.
The
parameter
element
may
contain
at
most
one
EnvelopedSignature
dsig2:Selection
dsig2:IncludedXPath
and
at
most
one
dsig2:ByteRange
parameter
element
to
modify
the
selection
result.
However
dsig2:IncludedXPath
must
not
be
removed,
because
in
an
enveloped
signature,
sign
an
EnvelopedSignature
without
excluding
present,
if
the
signature
itself.
URI
syntax
The
URI
can
be
an
external
reference
or
contains
a
same
document
reference.
Parameter
Syntax
<Selection Type SubType? URI>
(<IncludedXPath/>)?
(<ExcludedXPath/>)?
(<EnvelopedSignature/>)?
</Selection>
fragment
identifier.
Processing of the selection and parameters is as follows:
IncludedXPath
EnvelopedSignature
dsig2:ByteRange
parameter
is
The
canonicalization
algorithm
must
be
compatible
with
this
final
result
of
the
selection
output.
[
XML-C14N20
]
must
be
supported.
process
is
an
octet
stream.
Subtype
=
"http://www.w3.org/2010/xmldsig2#fromURI"
dsig2:Verification
Types
The
DigestDataLength
Type
=
"http://www.w3.org/2010/xmldsig2#binary"
dsig2:Verification
and
type
contains
an
integer
that
specifies
the
number
of
bytes
that
were
digested
for
the
containing
.
This
can
be
used
for
multiple
purposes:
Subtype
=
"http://www.w3.org/2010/xmldsig2#fromURI"
Parameters
Reference
The
non-negative
integer
value
is
carried
within
a
URI
DigestDataLength
should
be
an
external
reference.
Parameter
Syntax
attribute
inside
the
dsig2:Verification
element.
The
PositionAssertion
type
is
URI
dsig2:Verification
expected
used
to
be
increase
the
resistance
of
ID-based
referencing
to
signature
wrapping
attacks.
It
contains
an
external
reference.
Fetch
XPath
expression
that
must
match
the
document
as
referenced
content's
position
in
the
document.
Thus,
instead
of
"selecting"
the
referenced
element
via
an
octet
stream.
If
there
XPath,
its
position
is
verified
by
one
(which
enables
flexibility
in
the
actual
use
of
XPath
by
the
signer
or
verifier).
The
actual
selection
process
remains
ID-based,
which
is
simpler
for
many
implementers.
The
XPath
expression
is
carried
within
a
ByteRange
PositionAssertion
parameter,
create
a
new
octet
stream
with
a
subset
attribute
inside
the
dsig2:Verification
element.
While
using
the
PositionAssertion
feature
allows
more
flexibility
in
accomodating
XPath-unaware
signers
and
verifiers,
applications
should
favor
the
use
of
XPath-based
selection
via
the
bytes
fetched.
Alternatively
dsig2:IncludedXPath
element
over
the
use
of
this
can
be
combined
with
feature
in
most
cases.
Because
verification
of
the
first
step
PositionAssertion
is
formally
optional,
verifiers
may
become
subject
to
intelligently
fetch
only
positional
wrapping
attacks
if
they
choose
to
ignore
the
bytes
assertion.
This
feature
is
appropriate
mainly
in
applications
in
which
knowledge
of
the
byte
range.
Selection
Output
An
octet
stream
Canonicalization
No
canonicalization
should
verifier's
support
for
the
feature
can
be
used
with
this
type.
assured.
The
IDAttributes
type
is
used
in
conjunction
with
ID-based
references,
to
specify
the
ID
attribute
node
name
that
the
signer
used.
Ordinarily,
ID
attribute
knowledge
is
imparted
through
a
variety
of
normative
and
Type
=
"http://www.w3.org/2010/xmldsig2#binary"
dsig2:Verification
Subtype
=
"http://www.w3.org/2010/xmldsig2#fromBase64Node"
Parameters
URI
:
informal
means,
including
DTDs,
XML
Schemas,
use
of
xml:id,
and
application-specific
content
knowledge.
A
URI
signer
is
not
required
to
a
text
node.
See
section
URIs
for
2.0
mode
.
IncludedXPath
:
The
XPath
use
this
mechanism
to
be
include.
See
section
XPaths
in
2.0
mode
.
ByteRange
:
identify
ID
attributes,
but
may
do
so
to
transfer
its
own
ID
knowledge
to
the
verifier
through
the
signature
itself.
Verifiers
may
incorporate
this
knowledge,
or
use
more
traditional
means
of
recognizing
ID
attributes.
The
optional
byte
range
parameter
can
dsig2:Verification
element
specifies
exactly
one
ID
attribute
node.
This
must
be
used
to
indicate
that
only
a
portion
the
name
of
the
binary
data
should
be
signed.
E.g.
node
involved
in
the
containing
.ByteRange="0-20,220-270,320-"
Reference
The
dsig2:Verification
indicates
that
element
must
contain
one
of
the
first
following
two
child
elements:
20
dsig2:QualifiedAttr
220
Name
320
NS
URI
dsig2:UnqualifiedAttr
Name
attribute,
and
required
ParentName
and
optional
ParentNS
attributes
to
identify
the
Schema Definition: <xs:element name="QualifiedAttr" type="dsig2:QualifiedAttrType"/> <xs:complexType type="QualifiedAttrType"> <xs:attribute name="Name" type="xs:NCName" use="required"/> <xs:attribute name="NS" type="xs:anyURI" use="required"/> <xs:/complexType> <xs:element name="UnqualifiedAttr" type="dsig2:UnqualifiedAttrType"/> <xs:complexType type="UnqualifiedAttrType"> <xs:attribute name="Name" type="xs:NCName" use="required"/> <xs:attribute name="ParentName" type="xs:NCName" use="required"/> <xs:attribute name="ParentNS" type="xs:anyURI"/> <xs:/complexType>
Without
a
same
document
reference,
compute
the
subtree
pointed
DTD,
there
is
technically
no
way
to
by
define
IDness
in
an
XML
document.
In
practice,
this
reference.
If
it
is
typing
was
extended
to
documents
validated
by
an
external
reference,
fetch
the
document
XML
Schema,
and
use
an
xml
parser
then
to
parse
it
into
a
complete
document
tree.
Select
this
subtree
or
whole
document.
URI=""
indicates
the
whole
creation
of
the
current
document.
If
present,
evaluate
the
.
Unfortunately,
DTDs
have
mostly
fallen
out
of
IncludedXPath
with
the
context
set
at
the
root
xml:id
subtree/whole
document
identified
use
in
many
contexts,
and
schemas
are
expensive,
rarely
used
in
many
runtime
scenarios,
and
can't
be
relied
on
to
be
completely
known
by
the
URI.
The
xpath
expression
should
result
verifier
in
the
presence
of
extensible
XML
scenarios.
xml:id
has
not
yet
seen
wide
adoption,
mainly
because
a
single
element
node.
Modify
lot
of
the
selection
standards
that
needed
it
(SAML,
WS-Security)
were
completed
prior
to
include
only
its
invention.
The
result
is
that
subtree
identified
by
this
element
node.
Coalesce
all
the
text
node
values
into
one
large
string
and
Base64
Decode
applications
that
string
rely
on
ID-based
references
for
signing
have
typically
made
insecure
assumptions
about
the
IDness
of
attributes
based
on
their
name
(
ID
,
id
,
Id
,
etc.),
or
have
to
obtain
an
octet
stream.
If
there
provide
APIs
for
applications
to
call
before
verification
(which
is
also
a
ByteRange
parameter,
create
a
new
octet
stream
with
a
subset
problem
in
the
face
of
extensibility).
DOM
Level
3,
which
is
now
fairly
widely
implemented,
also
provides
the
bytes
in
ability
to
identify
attributes
as
an
ID
at
runtime,
although
often
without
guaranteeing
the
previous
step.
Selection
Output
An
octet
stream
Canonicalization
No
canonicalization
should
be
used
with
this
type.
6.8
"2.0
Mode"
Canonicalization
Algorithms
[
XML-C14N20
]
must
be
supported.
This
algorithm's
input
consists
of:
uniqueness
property.
The
IDAttributes
verification
type
provides
a
list
deterministic
way
of
subtrees
with
exclusions
parameter
values
In
addition
applications
may
also
support
other
canonicalization
algorithms
defining
an
ID
attribute
used
during
signing,
that
support
the
same
input
model
(subtrees
with
exclusions).
User
defined
Selection
Types
may
define
their
own
canonicalization
algorithms,
which
may
use
this
input
model
is
independent
of
DTD,
XML
Schema,
DOM
3
or
even
a
different
one.
other
application-specific
mechanisms.
Digital signatures only work if the verification calculations are performed on exactly the same bits as the signing calculations. If the surface representation of the signed data can change between signing and verification, then some way to standardize the changeable aspect must be used before signing and verification. For example, even for simple ASCII text there are at least three widely used line ending sequences. If it is possible for signed text to be modified from one line ending convention to another between the time of signing and signature verification, then the line endings need to be canonicalized to a standard form before signing and verification or the signatures will break.
XML is subject to surface representation changes and to processing which discards some surface information. For this reason, XML digital signatures have a provision for indicating canonicalization methods in the signature so that a verifier can use the same canonicalization as the signer.
Throughout
this
specification
we
distinguish
between
the
canonicalization
of
a
Signature
element
and
other
signed
XML
data
objects.
It
is
possible
for
an
isolated
XML
document
to
be
treated
as
if
it
were
binary
data
so
that
no
changes
can
occur.
In
that
case,
the
digest
of
the
document
will
not
change
and
it
need
not
be
canonicalized
if
it
is
signed
and
verified
as
such.
However,
XML
that
is
read
and
processed
using
standard
XML
parsing
and
processing
techniques
is
frequently
changed
such
that
some
of
its
surface
representation
information
is
lost
or
modified.
In
particular,
this
will
occur
in
many
cases
for
the
Signature
and
enclosed
SignedInfo
elements
since
they,
and
possibly
an
encompassing
XML
document,
will
be
processed
as
XML.
Similarly,
these
considerations
apply
to
Manifest
,
Object
,
and
SignatureProperties
elements
if
those
elements
have
been
digested,
their
DigestValue
is
to
be
checked,
and
they
are
being
processed
as
XML.
The
kinds
of
changes
in
XML
that
may
need
to
be
canonicalized
can
be
divided
into
four
categories.
There
are
those
related
to
the
basic
[
XML10
],
as
described
in
7.1
below.
There
are
those
related
to
[
DOM-LEVEL-1
],
[
SAX
],
or
similar
processing
as
described
in
7.2
below.
Third,
there
is
the
possibility
of
coded
character
set
conversion,
such
as
between
UTF-8
and
UTF-16,
both
of
which
all
all
[
XML10
]
compliant
processors
are
required
to
support,
which
is
described
in
the
paragraph
immediately
below.
And,
fourth,
there
are
changes
that
related
to
namespace
declaration
and
XML
namespace
attribute
context
as
described
in
7.3
below.
Any
canonicalization
algorithm
should
yield
output
in
a
specific
fixed
coded
character
set.
All
canonicalization
algorithms
identified
in
this
document
use
UTF-8
(without
a
byte
order
mark
(BOM))
and
do
not
provide
character
normalization.
We
RECOMMEND
that
signature
applications
create
XML
content
(
Signature
elements
and
their
descendants/content)
in
Normalization
Form
C
[
NFC
]
and
check
that
any
XML
being
consumed
is
in
that
form
as
well;
(if
not,
signatures
may
consequently
fail
to
validate).
Additionally,
none
of
these
algorithms
provide
data
type
normalization.
Applications
that
normalize
data
types
in
varying
formats
(e.g.,
(true,
false)
or
(1,0))
may
not
be
able
to
validate
each
other's
signatures.
XML 1.0 [ XML10 ]] defines an interface where a conformant application reading XML is given certain information from that XML and not other information. In particular,
Note
that
items
(2),
(4),
and
(5.3)
depend
on
the
presence
of
a
schema,
DTD
or
similar
declarations.
The
Signature
element
type
is
laxly
schema
valid
[
XMLSCHEMA-1
][
XMLSCHEMA-2
],
consequently
external
XML
or
even
XML
within
the
same
document
as
the
signature
may
be
(only)
well-formed
or
from
another
namespace
(where
permitted
by
the
signature
schema);
the
noted
items
may
not
be
present.
Thus,
a
signature
with
such
content
will
only
be
verifiable
by
other
signature
applications
if
the
following
syntax
constraints
are
observed
when
generating
any
signed
material
including
the
SignedInfo
element:
In
addition
to
the
canonicalization
and
syntax
constraints
discussed
above,
many
XML
applications
use
the
Document
Object
Model
[
DOM-LEVEL-1
]
or
the
Simple
API
for
XML
XML
[
SAX
].
DOM
maps
XML
into
a
tree
structure
of
nodes
and
typically
assumes
it
will
be
used
on
an
entire
document
with
subsequent
processing
being
done
on
this
tree.
SAX
converts
XML
into
a
series
of
events
such
as
a
start
tag,
content,
etc.
In
either
case,
many
surface
characteristics
such
as
the
ordering
of
attributes
and
insignificant
white
space
within
start/end
tags
is
lost.
In
addition,
namespace
declarations
are
mapped
over
the
nodes
to
which
they
apply,
losing
the
namespace
prefixes
in
the
source
text
and,
in
most
cases,
losing
where
namespace
declarations
appeared
in
the
original
instance.
If
an
XML
Signature
is
to
be
produced
or
verified
on
a
system
using
the
DOM
or
SAX
processing,
a
canonical
method
is
needed
to
serialize
the
relevant
part
of
a
DOM
tree
or
sequence
of
SAX
events.
XML
canonicalization
specifications,
such
as
[
XML-C14N
],
are
based
only
on
information
which
is
preserved
by
DOM
and
SAX.
For
an
XML
Signature
to
be
verifiable
by
an
implementation
using
DOM
or
SAX,
not
only
must
the
XML
1.0
syntax
constraints
given
in
the
previous
section
11.1
XML
1.0
Syntax
Constraints,
and
Canonicalization
be
followed
but
an
appropriate
XML
canonicalization
must
be
specified
so
that
the
verifier
can
re-serialize
DOM/SAX
mediated
input
into
the
same
octet
stream
that
was
signed.
In [ XPATH ] and consequently the Canonical XML data model an element has namespace nodes that correspond to those declarations within the element and its ancestors:
" Note: An element E has namespace nodes that represent its namespace declarations as well as any namespace declarations made by its ancestors that have not been overridden in E 's declarations, the default namespace if it is non-empty, and the declaration of the prefix
xml
." [ XML-C14N ]
When
serializing
a
Signature
element
or
signed
XML
data
that's
the
child
of
other
elements
using
these
data
models,
that
Signature
element
and
its
children,
may
contain
namespace
declarations
from
its
ancestor
context.
In
addition,
the
Canonical
XML
and
Canonical
XML
with
Comments
algorithms
import
all
XML
namespace
attributes
(such
as
xml:lang
)
from
the
nearest
ancestor
in
which
they
are
declared
to
the
apex
node
of
canonicalized
XML
unless
they
are
already
declared
at
that
node.
This
may
frustrate
the
intent
of
the
signer
to
create
a
signature
in
one
context
which
remains
valid
in
another.
For
example,
given
a
signature
which
is
a
child
of
B
and
a
grandchild
of
A
:
<A xmlns:n1="&foo;"> <B xmlns:n2="&bar;"> <Signature xmlns="&dsig;"> ... <Reference URI="#signme"/> ... </Signature> <C ID="signme" xmlns="&baz;"/> </B> </A>
when
either
the
element
B
or
the
signed
element
C
is
moved
into
a
[
SOAP12-PART1
]
envelope
for
transport:
<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"> ... <SOAP:Body> <B xmlns:n2="&bar;"> <Signature xmlns="&dsig;"> ... </Signature> <C ID="signme" xmlns="&baz;"/> </B> </SOAP:Body> </SOAP:Envelope>
The
canonical
form
of
the
signature
in
this
context
will
contain
new
namespace
declarations
from
the
SOAP:Envelope
context,
invalidating
the
signature.
Also,
the
canonical
form
will
lack
namespace
declarations
it
may
have
originally
had
from
element
A
's
context,
also
invalidating
the
signature.
To
avoid
these
problems,
the
application
may:
The XML Signature specification provides a very flexible digital signature mechanism. Implementers must give consideration to their application threat models and to the following factors. For additional security considerations in implementation and deployment of this specification, see [ XMLDSIG-BESTPRACTICES ].
A
requirement
of
this
specification
is
to
permit
signatures
to
"apply
to a
to
a
part
or
totality
of
a
XML
document."
(See
[
XMLDSIG-REQUIREMENTS
],
section
3.1.3].)
The
Transforms
mechanism
meets
this
requirement
by
permitting
one
to
sign
data
derived
from
processing
the
content
of
the
identified
resource.
For
instance,
applications
that
wish
to
sign
a
form,
but
permit
users
to
enter
limited
field
data
without
invalidating
a
previous
signature
on
the
form
might
use
[
XPATH
]
to
exclude
those
portions
the
user
needs
to
change.
Transforms
may
be
arbitrarily
specified
and
may
include
encoding
transforms,
canonicalization
instructions
or
even
XSLT
transformations.
Three
cautions
are
raised
with
respect
to
this
feature
in
the
following
sections.
Note,
core
validation
behavior
does
not
confirm
that
the
signed
data
was
obtained
by
applying
each
step
of
the
indicated
transforms.
(Though
it
does
check
that
the
digest
of
the
resulting
content
matches
that
specified
in
the
signature.)
signature.)
For
example,
some
applications
may
be
satisfied
with
verifying
an
XML
signature
over
a
cached
copy
of
already
transformed
data.
Other
applications
might
require
that
content
be
freshly
dereferenced
and
transformed.
First, obviously, signatures over a transformed document do not secure any information discarded by transforms: only what is signed is secure.
Note
that
the
use
of
Canonical
Canonical
XML
[
XML-C14N
]
ensures
that
all
internal
entities
and
XML
namespaces
are
expanded
within
the
content
being
signed.
All
entities
are
replaced
with
their
definitions
and
the
canonical
form
explicitly
represents
the
namespace
that
an
element
would
otherwise
inherit.
Applications
that
do
not
canonicalize
XML
content
(especially
the
SignedInfo
element)
should
not
use
internal
entities
and
should
represent
the
namespace
explicitly
within
the
content
being
signed
since
they
can
not
rely
upon
canonicalization
to
do
this
for
them.
Also,
users
concerned
with
the
integrity
of
the
element
type
definitions
associated
with
the
XML
instance
being
signed
may
wish
to
sign
those
definitions
as
well
(i.e.,
the
schema,
DTD,
or
natural
language
description
associated
with
the
namespace/identifier).
Second, an envelope containing signed information is not secured by the signature. For instance, when an encrypted envelope contains a signature, the signature does not protect the authenticity or integrity of unsigned envelope headers nor its ciphertext form, it only secures the plaintext actually signed.
Additionally, the signature secures any information introduced by the transform: only what is "seen" (that which is represented to the user via visual, auditory or other media) should be signed. If signing is intended to convey the judgment or consent of a user (an automated mechanism or person), then it is normally necessary to secure as exactly as practical the information that was presented to that user. Note that this can be accomplished by literally signing what was presented, such as the screen images shown a user. However, this may result in data which is difficult for subsequent software to manipulate. Instead, one can sign the data along with whatever filters, style sheets, client profile or other information that affects its presentation.
Just
as
a
user
should
only
sign
what
he
or
she
"sees,"
persons
and
automated
mechanism
that
trust
the
validity
of
a
transformed
document
on
the
basis
of
a
valid
signature
should
operate
over
the
data
that
was
transformed
(including
canonicalization)
and
signed,
not
the
original
pre-transformed
data.
This
recommendation
applies
to
transforms
specified
within
the
signature
as
well
as
those
included
as
part
of
the
document
itself.
For
instance,
if
an
XML
document
includes
an
embedded
style
sheet
[
XSLT
]
it
is
the
transformed
document
that
should
be
represented
to
the
user
and
signed.
To
meet
this
recommendation
where
a
document
references
an
external
style
sheet,
the
content
of
that
external
resource
should
also
be
signed
as
via
a
signature
Reference
otherwise
the
content
of
that
external
content
might
change
which
alters
the
resulting
document
without
invalidating
the
signature.
Some applications might operate over the original or intermediary data but should be extremely careful about potential weaknesses introduced between the original and transformed data. This is a trust decision about the character and meaning of the transforms that an application needs to make with caution. Consider a canonicalization algorithm that normalizes character case (lower to upper) or character composition ('e and accent' to 'accented-e'). An adversary could introduce changes that are normalized and consequently inconsequential to signature validity but material to a DOM processor. For instance, by changing the case of a character one might influence the result of an XPath selection. A serious risk is introduced if that change is normalized for signature validation but the processor operates over the original data and returns a different result than intended.
As a result:
This specification uses public key signatures and keyed hash authentication codes. These have substantially different security models. Furthermore, it permits user specified algorithms which may have other models.
With public key signatures, any number of parties can hold the public key and verify signatures while only the parties with the private key can create signatures. The number of holders of the private key should be minimized and preferably be one. Confidence by verifiers in the public key they are using and its binding to the entity or capabilities represented by the corresponding private key is an important issue, usually addressed by certificate or online authority systems.
Keyed hash authentication codes, based on secret keys, are typically much more efficient in terms of the computational effort required but have the characteristic that all verifiers need to have possession of the same key as the signer. Thus any verifier can forge signatures.
This specification permits user provided signature algorithms and keying information designators. Such user provided algorithms may have different security models. For example, methods involving biometrics usually depend on a physical characteristic of the authorized user that can not be changed the way public or secret keys can be and may have other security model differences.
The strength of a particular signature depends on all links in the security chain. This includes the signature and digest algorithms used, the strength of the key generation [ RANDOM ] and the size of the key, the security of key and certificate authentication and distribution mechanisms, certificate chain validation policy, protection of cryptographic processing from hostile observation and tampering, etc.
Care must be exercised by applications in executing the various algorithms that may be specified in an XML signature and in the processing of any "executable content" that might be provided to such algorithms as parameters, such as XSLT transforms. The algorithms specified in this document will usually be implemented via a trusted library but even there perverse parameters might cause unacceptable processing or memory demand. Even more care may be warranted with application defined algorithms.
The security of an overall system will also depend on the security and integrity of its operating procedures, its personnel, and on the administrative enforcement of those procedures. All the factors listed in this section are important to the overall security of a system; however, most are beyond the scope of this specification.
This section is non-normative.
Object
designates
a
specific
XML
element.
Occasionally
we
refer
to
a
data
object
as
a
document
or
as
a
resource
's
content
.
The
term
element
content
is
used
to
describe
the
data
between
XML
start
and
end
tags
[
XML10
].
The
term
XML
document
is
used
to
describe
data
objects
which
conform
to
the
XML
specification
[
XML10
].
Object
element
is
merely
one
type
of
digital
data
(or
document)
that
can
be
signed
via
a
Reference
.
Signature
element
type
and
its
children
(including
SignatureValue
)
and
the
specified
algorithms.
Signature
element,
and
can
be
identified
via
a
URI
or
transform.
Consequently,
the
signature
is
"detached"
from
the
content
it
signs.
This
definition
typically
applies
to
separate
data
objects,
but
it
also
includes
the
instance
where
the
Signature
and
data
object
reside
within
the
same
XML
document
but
are
sibling
elements.
Object
element
of
the
signature
itself.
The
Object
(or
its
content)
is
identified
via
a
Reference
(via
a
URI
fragment
identifier
or
transform).
SignatureValue
.
SignedInfo
reference
validation
.
Reference
,
matches
its
specified
DigestValue
.
SignatureValue
matches
the
result
of
processing
SignedInfo
CanonicalizationMethod
and
SignatureMethod
as
specified
in
section
4.3
Core
Validation
Use of the "Compatibility Mode" described in this section enables the XML Signature 1.x model to be used where necessary, to enable backward compatibility.
The following examples are for a detached signature of the content of the HTML4 in XML specification.
This example uses "Compatibility Mode".
[s01] <Signature Id="MyFirstSignature" xmlns="http://www.w3.org/2000/09/xmldsig#"> [s02] <SignedInfo> [s03] <CanonicalizationMethod Algorithm="http://www.w3.org/2006/12/xml-c14n11"/> [s04] <SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/> [s05] <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/"> [s06] <Transforms> [s07] <Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/> [s08] </Transforms> [s09] <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> [s10] <DigestValue>dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...</DigestValue> [s11] </Reference> [s12] </SignedInfo> [s13] <SignatureValue>...</SignatureValue> [s14] <KeyInfo> [s15a] <KeyValue> [s15b] <DSAKeyValue> [s15c] <P>...</P><Q>...</Q><G>...</G><Y>...</Y> [s15d] </DSAKeyValue> [s15e] </KeyValue> [s16] </KeyInfo> [s17] </Signature>
[s02-12]
The
required
SignedInfo
element
is
the
information
that
is
actually
signed.
Core
validation
of
SignedInfo
consists
of
two
mandatory
processes:
validation
of
the
signature
over
SignedInfo
and
validation
of
each
Reference
digest
within
SignedInfo
.
Note
that
the
algorithms
used
in
calculating
the
SignatureValue
are
also
included
in
the
signed
information
while
the
SignatureValue
element
is
outside
SignedInfo
.
[s03]
The
CanonicalizationMethod
is
the
algorithm
that
is
used
to
canonicalize
the
SignedInfo
element
before
it
is
digested
as
part
of
the
signature
operation.
Note
that
this
example
is
not
in
canonical
form.
(None
of
the
examples
in
this
specification
are
in
canonical
form.)
[s04]
The
SignatureMethod
is
the
algorithm
that
is
used
to
convert
the
canonicalized
SignedInfo
into
the
SignatureValue
.
It
is
a
combination
of
a
digest
algorithm
and
a
key
dependent
algorithm
and
possibly
other
algorithms
such
as
padding,
for
example
RSA-SHA1.
The
algorithm
names
are
signed
to
resist
attacks
based
on
substituting
a
weaker
algorithm.
To
promote
application
interoperability
we
specify
a
set
of
signature
algorithms
that
must
be
implemented,
though
their
use
is
at
the
discretion
of
the
signature
creator.
We
specify
additional
algorithms
as
recommended
or
optional
for
implementation;
the
design
also
permits
arbitrary
user
specified
algorithms.
[s05-11]
Each
Reference
element
includes
the
digest
method
and
resulting
digest
value
calculated
over
the
identified
data
object.
It
also
may
include
transformations
that
produced
the
input
to
the
digest
operation.
A
data
object
is
signed
by
computing
its
digest
value
and
a
signature
over
that
value.
The
signature
is
later
checked
via
reference
and
signature
validation
.
[s14-16]
KeyInfo
indicates
the
key
to
be
used
to
validate
the
signature.
Possible
forms
for
identification
include
certificates,
key
names,
and
key
agreement
algorithms
and
information
--
we
define
only
a
few.
KeyInfo
is
optional
for
two
reasons.
First,
the
signer
may
not
wish
to
reveal
key
information
to
all
document
processing
parties.
Second,
the
information
may
be
known
within
the
application's
context
and
need
not
be
represented
explicitly.
Since
KeyInfo
is
outside
of
SignedInfo
,
if
the
signer
wishes
to
bind
the
keying
information
to
the
signature,
a
Reference
can
easily
identify
and
include
the
KeyInfo
as
part
of
the
signature.
Use
of
KeyInfo
is
optional,
however
note
that
senders
and
receivers
must
agree
on
how
it
will
be
used
through
a
mechanism
out
of
scope
for
this
specification.
Reference
These
section
explaining
the
lines
[s05]
to
[s11]
of
the
previous
example.
This
signature
is
in
"compatibility
mode".
[s05] <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/"> [s06] <Transforms> [s07] <Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/> [s08] </Transforms> [s09] <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> [s10] <DigestValue>dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...</DigestValue> [s11] </Reference>
[s05]
The
optional
URI
attribute
of
Reference
identifies
the
data
object
to
be
signed.
This
attribute
may
be
omitted
on
at
most
one
Reference
in
a
Signature
.
(This
limitation
is
imposed
in
order
to
ensure
that
references
and
objects
may
be
matched
unambiguously.)
[s05-08]
This
identification,
along
with
the
transforms,
is
a
description
provided
by
the
signer
on
how
they
obtained
the
signed
data
object
in
the
form
it
was
digested
(i.e.
the
digested
content).
The
verifier
may
obtain
the
digested
content
in
another
method
so
long
as
the
digest
verifies.
In
particular,
the
verifier
may
obtain
the
content
from
a
different
location
such
as
a
local
store
than
that
specified
in
the
URI
.
[s06-08]
Transforms
is
an
optional
ordered
list
of
processing
steps
that
were
applied
to
the
resource's
content
before
it
was
digested.
Transforms
can
include
operations
such
as
canonicalization,
encoding/decoding
(including
compression/inflation),
XSLT,
XPath,
XML
schema
validation,
or
XInclude.
XPath
transforms
permit
the
signer
to
derive
an
XML
document
that
omits
portions
of
the
source
document.
Consequently
those
excluded
portions
can
change
without
affecting
signature
validity.
For
example,
if
the
resource
being
signed
encloses
the
signature
itself,
such
a
transform
must
be
used
to
exclude
the
signature
value
from
its
own
computation.
If
no
Transforms
element
is
present,
the
resource's
content
is
digested
directly.
While
the
Working
Group
has
specified
mandatory
(and
optional)
canonicalization
and
decoding
algorithms,
user
specified
transforms
are
permitted.
[s09-10]
DigestMethod
is
the
algorithm
applied
to
the
data
after
Transforms
is
applied
(if
specified)
to
yield
the
DigestValue
.
The
signing
of
the
DigestValue
is
what
binds
the
content
of
a
resource
to
the
signer's
key.
Object
and
SignatureProperty
)
This
specification
does
not
address
mechanisms
for
making
statements
or
assertions.
Instead,
this
document
defines
what
it
means
for
something
to
be
signed
by
an
XML
Signature
(
integrity
,
message
authentication
,
and/or
signer
authentication
).
Applications
that
wish
to
represent
other
semantics
must
rely
upon
other
technologies,
such
as
[
XML10
],
[
RDF-PRIMER
].
For
instance,
an
application
might
use
a
foo:assuredby
attribute
within
its
own
markup
to
reference
a
Signature
element.
Consequently,
it's
the
application
that
must
understand
and
know
how
to
make
trust
decisions
given
the
validity
of
the
signature
and
the
meaning
of
assuredby
syntax.
We
also
define
a
SignatureProperties
element
type
for
the
inclusion
of
assertions
about
the
signature
itself
(e.g.,
signature
semantics,
the
time
of
signing
or
the
serial
number
of
hardware
used
in
cryptographic
processes).
Such
assertions
may
be
signed
by
including
a
Reference
for
the
SignatureProperties
in
SignedInfo
.
While
the
signing
application
should
be
very
careful
about
what
it
signs
(it
should
understand
what
is
in
the
SignatureProperty
)
a
receiving
application
has
no
obligation
to
understand
that
semantic
(though
its
parent
trust
engine
may
wish
to).
Any
content
about
the
signature
generation
may
be
located
within
the
SignatureProperty
element.
The
mandatory
Target
attribute
references
the
Signature
element
to
which
the
property
applies.
Consider
the
preceding
example
(in
"Compatibility
Mode")
with
an
additional
reference
to
a
local
Object
that
includes
a
SignatureProperty
element.
(Such
a
signature
would
not
only
be
detached
[p02]
but
enveloping
[p03]
.)
[ ] <Signature Id="MySecondSignature" ...> [p01] <SignedInfo> [ ] ... [p02] <Reference URI="http://www.w3.org/TR/xml-stylesheet/"> [ ] ... [p03] <Reference URI="#AMadeUpTimeStamp" [p04] Type="http://www.w3.org/2000/09/xmldsig#SignatureProperties"> [p05] <Transforms> [p06] <Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/> [p07] </Transforms> [p08] <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> [p09] <DigestValue>dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...</DigestValue> [p10] </Reference> [p11] </SignedInfo> [p12] ... [p13] <Object> [p14] <SignatureProperties> [p15] <SignatureProperty Id="AMadeUpTimeStamp" Target="#MySecondSignature"> [p16] <timestamp xmlns="http://www.ietf.org/rfcXXXX.txt"> [p17] <date>19990914</date> [p18] <time>14:34:34:34</time> [p19] </timestamp> [p20] </SignatureProperty> [p21] </SignatureProperties> [p22] </Object> [p23] </Signature>
[p04]
The
optional
Type
attribute
of
Reference
provides
information
about
the
resource
identified
by
the
URI
.
In
particular,
it
can
indicate
that
it
is
an
Object
,
SignatureProperty
,
or
Manifest
element.
This
can
be
used
by
applications
to
initiate
special
processing
of
some
Reference
elements.
References
to
an
XML
data
element
within
an
Object
element
should
identify
the
actual
element
pointed
to.
Where
the
element
content
is
not
XML
(perhaps
it
is
binary
or
encoded
data)
the
reference
should
identify
the
Object
and
the
Reference
Type
,
if
given,
should
indicate
Object
.
Note
that
Type
is
advisory
and
no
action
based
on
it
or
checking
of
its
correctness
is
required
by
core
behavior.
[p13]
Object
is
an
optional
element
for
including
data
objects
within
the
signature
element
or
elsewhere.
The
Object
can
be
optionally
typed
and/or
encoded.
[p14-21]
Signature
properties,
such
as
time
of
signing,
can
be
optionally
signed
by
identifying
them
from
within
a
Reference
.
(These
properties
are
traditionally
called
signature
"attributes"
although
that
term
has
no
relationship
to
the
XML
term
"attribute".)
This
is
the
same
example
in
"2.0
Mode".
Only
the
Reference
content
is
different.
[ ] ... [p03] <Reference> [p04] [p05] <Transforms> [p06] <Transform Algorithm="http://www.w3.org/2010/xmldsig2#transform"> [s06a] <dsig2:Selection type="http://www.w3.org/2010/xmldsig2#xml" xmlns:dsig2="http://www.w3.org/2010/xmldsig2#" URI="#AMadeUpTimeStamp" > [p06b] </dsig2:Selection> [p06c] <CanonicalizationMethod Algorithm="http://www.w3.org/2010/xml-c14n2"/> [p06d] </Transform> [p07] </Transforms> [p08] <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> [p09] <DigestValue>dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...</DigestValue> [p10] </Reference> [ ] ...
Object
and
Manifest
)
The
Manifest
element
is
provided
to
meet
additional
requirements
not
directly
addressed
by
the
mandatory
parts
of
this
specification.
Two
requirements
and
the
way
the
Manifest
satisfies
them
follow.
First,
applications
frequently
need
to
efficiently
sign
multiple
data
objects
even
where
the
signature
operation
itself
is
an
expensive
public
key
signature.
This
requirement
can
be
met
by
including
multiple
Reference
elements
within
SignedInfo
since
the
inclusion
of
each
digest
secures
the
data
digested.
However,
some
applications
may
not
want
the
core
validation
behavior
associated
with
this
approach
because
it
requires
every
Reference
within
SignedInfo
to
undergo
reference
validation
--
the
DigestValue
elements
are
checked.
These
applications
may
wish
to
reserve
reference
validation
decision
logic
to
themselves.
For
example,
an
application
might
receive
a
signature
valid
SignedInfo
element
that
includes
three
Reference
elements.
If
a
single
Reference
fails
(the
identified
data
object
when
digested
does
not
yield
the
specified
DigestValue
)
the
signature
would
fail
core
validation
.
However,
the
application
may
wish
to
treat
the
signature
over
the
two
valid
Reference
elements
as
valid
or
take
different
actions
depending
on
which
fails.
To
accomplish
this,
SignedInfo
would
reference
a
Manifest
element
that
contains
one
or
more
Reference
elements
(with
the
same
structure
as
those
in
SignedInfo
).
Then,
reference
validation
of
the
Manifest
is
under
application
control.
Second,
consider
an
application
where
many
signatures
(using
different
keys)
are
applied
to
a
large
number
of
documents.
An
inefficient
solution
is
to
have
a
separate
signature
(per
key)
repeatedly
applied
to
a
large
SignedInfo
element
(with
many
Reference
s);
this
is
wasteful
and
redundant.
A
more
efficient
solution
is
to
include
many
references
in
a
single
Manifest
that
is
then
referenced
from
multiple
Signature
elements.
The
example
(in
"Compatibility
Mode")
below
includes
a
Reference
that
signs
a
Manifest
found
within
the
Object
element.
[ ] ... [m01] <Reference URI="#MyFirstManifest" [m02] Type="http://www.w3.org/2000/09/xmldsig#Manifest"> [m03] <Transforms> [m04] <Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/> [m05] </Transforms> [m06] <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> [m07] <DigestValue>dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...=</DigestValue> [m08] </Reference> [ ] ... [m09] <Object> [m10] <Manifest Id="MyFirstManifest"> [m11] <Reference> [m12] ... [m13] </Reference> [m14] <Reference> [m15] ... [m16] </Reference> [m17] </Manifest> [m18] </Object>
Here
is
the
modified
Reference
in
"2.0
Mode"
[m01] <Reference [m02] Type="http://www.w3.org/2000/09/xmldsig#Manifest"> [m03] <Transforms> [m04] <Transform Algorithm="http://www.w3.org/2010/xmldsig2#transform"> [m04a] <dsig2:Selection type="http://www.w3.org/2010/xmldsig2#xml" xmlns:dsig2="http://www.w3.org/2010/xmldsig2#" URI="#MyFirstManifest"> [m04b] </dsig2:Selection> [m04c] <CanonicalizationMethod Algorithm="http://www.w3.org/2010/xml-c14n2"/> [m04d] </Transform> [m05] </Transforms> [m06] <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/> [m07] <DigestValue>dGhpcyBpcyBub3QgYSBzaWduYXR1cmUK...=</DigestValue> [m08] </Reference>
For each data object being signed:
Transforms
,
as
determined
by
the
application,
to
the
data
object.
Reference
element,
including
the
(optional)
identification
of
the
data
object,
any
(optional)
transform
elements,
the
digest
algorithm
and
the
DigestValue
.
(Note,
it
is
the
canonical
form
of
these
references
that
are
signed
in
3.1.3
and
validated
in
3.2.1
.)
Transform
elements
is
a
node-set.
We
RECOMMEND
that,
when
generating
signatures,
signature
applications
do
not
rely
on
this
default
behavior,
but
explicitly
identify
the
transformation
that
is
applied
to
perform
this
mapping.
In
cases
in
which
inclusive
canonicalization
is
desired,
we
RECOMMEND
that
Canonical
XML
1.1
[
XML-C14N11
]
be
used.
It
is
very
important
to
check
that
the
Reference
actually
includes
the
data
that
is
expected
to
be
signed.
The
[
XMLDSIG-BESTPRACTICES
]
document
describes
a
number
of
attacks,
where
what
is
apparently
being
signed
is
not
actually
signed.
One way to check the reference is to allow only certain combinations of transforms. For example [ SAML2-CORE ] and [ EBXML-MSG ] follow this approach.
Another option is for XML Signature libraries to return the pre-digest data to the application, so that application can inspect it to verify what is actually signed. This too may not be enough, for example in a Web Services scenario, if the reference is pointing to a soap:Body, it is not sufficient to just check the name of the "soap:Body" element, as it can lead to wrapping attacks [ MCINTOSH-WRAP ];Instead the application should check if this soap:Body is in the correct position, i.e. as a child of the top level soap:Envelope.
KeyInfo
or
from
an
external
source.
SignatureMethod
using
the
CanonicalizationMethod
and
use
the
result
(and
previously
obtained
KeyInfo
)
to
confirm
the
SignatureValue
over
the
SignedInfo
element.
Note,
KeyInfo
(or
some
transformed
version
thereof)
may
be
signed
via
a
Reference
element.
Transformation
and
validation
of
this
reference
(3.2.1)
is
orthogonal
to
Signature
Validation
which
uses
the
KeyInfo
as
parsed.
Additionally,
the
SignatureMethod
URI
may
have
been
altered
by
the
canonicalization
of
SignedInfo
(e.g.,
absolutization
of
relative
URIs)
and
it
is
the
canonical
form
that
must
be
used.
However,
the
required
canonicalization
[
XML-C14N
]
of
this
specification
does
not
change
URIs.
SignedInfo
element
based
on
the
CanonicalizationMethod
in
SignedInfo
.
Reference
in
SignedInfo
:
URI
and
execute
Transforms
provided
by
the
signer
in
the
Reference
element,
or
it
may
obtain
the
content
through
other
means
such
as
a
local
cache.)
DigestMethod
specified
in
its
Reference
specification.
DigestValue
in
the
SignedInfo
Reference
;
if
there
is
any
mismatch,
validation
fails.
Note,
SignedInfo
is
canonicalized
in
step
1.
The
application
must
ensure
that
the
CanonicalizationMethod
has
no
dangerous
side
effects,
such
as
rewriting
URIs,
(see
CanonicalizationMethod
Note
in
section
B.3
Use
of
CanonicalizationMethod
in
"Compatibility
Mode"
)
and
that
it
"Sees
What
is
Signed",
which
is
the
canonical
form
(see
section
12.1.3
"See"
What
is
Signed
).
Note,
After
a
Signature
element
has
been
created
during
Signature
Generation
for
a
signature
with
a
same
document
reference,
an
implementation
can
serialize
the
XML
content
with
variations
in
that
serialization.
This
means
that
Reference
Validation
needs
to
canonicalize
the
XML
document
before
digesting
in
step
1
to
avoid
issues
related
to
variations
in
serialization.
CanonicalizationMethod
in
"Compatibility
Mode"
Alternatives to the required section B.6 "Compatibility Mode" Canonicalization Algorithms , such as section B.6.1 Canonical XML 1.0 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 section 11. XML Canonicalization and Syntax Constraint Considerations . 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 12.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:
SignedInfo
and
currently
indicating
the
SignedInfo
,
its
descendants,
and
the
attribute
and
namespace
nodes
of
SignedInfo
and
its
descendant
elements.
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
Reference
s
being
validated.
Or,
the
method
could
significantly
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.
URI
Attribute
in
"Compatibility
Mode"
If
the
URI
attribute
is
omitted
for
a
"Compatibility
Mode"
signature,
then
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.
In
"Compatibility
Mode",
at
most
one
Reference
element
without
a
URI
attribute
may
be
present
in
any
particular
SignedInfo
,
or
Manifest
.
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 section 4.3 Core Validation for further information on reference processing.)
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.
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 are 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:
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 section B.2.1 Reference Generation in "Compatibility Mode" 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 section 6.2 The Transforms Element .)
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
section
B.4.2
"Compatibility
Mode"
Same-Document
URI-References
.)
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"
URI="http://example.com/bar.xml#chapter1"
URI=""
URI="#chapter1"
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:
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 section B.4.1 The "Compatibility Mode" Reference Processing Model .
If
the
optional
Transforms
element
is
present
and
contains
exactly
one
Transform
element
with
an
Algorithm
of
"http://www.w3.org/2010/xmldsig2#transform"
then
2.0
processing
is
performed
as
described
in
section
6.2
The
Transforms
Element
otherwise
compatibility
mode
transform
processing
is
performed
as
described
here.
The
optional
Transforms
element
contains
an
ordered
list
of
Transform
elements;
these
describe
how
the
signer
obtained
the
data
object
that
was
digested.
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.
The
Transforms
element
is
optional
and
its
presence
indicates
that
the
signer
is
not
signing
the
native
(original)
document
but
the
resulting
(transformed)
document.
(See
section
12.1.1
Only
What
is
Signed
is
Secure
).
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.
As described in section B.4.1 The "Compatibility Mode" Reference Processing Model , some transforms take an XPath node-set as input, while others require an octet stream. If the actual input matches the input needs of the transform, then the transform operates on the unaltered input. If the transform input requirement differs from the format of the actual input, then the input must be converted.
Some
Transform
s
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.
section
B.7
"Compatibility
Mode"
Transform
Algorithms
defines
the
list
of
standard
"Compatibility
Mode"
transformations.
If canonicalization is performed over octets, the canonicalization algorithms take two implicit parameters: the content and its charset. The charset is derived according to the rules of the transport protocols and media types (e.g, [ XML-MEDIA-TYPES ] defines the media types for XML). This information is necessary to correctly sign and verify documents and often requires careful server side configuration.
Various canonicalization algorithms require conversion to [ UTF-8 ]. The algorithms below understand at least [ UTF-8 ] and [ UTF-16 ] as input encodings. We RECOMMEND that externally specified algorithms do the same. Knowledge of other encodings is optional .
Various canonicalization algorithms transcode from a non-Unicode encoding to Unicode. The output of these algorithms will be in NFC [ NFC ]. This is because the XML processor used to prepare the XPath data model input is required (by the Data Model) to use Normalization Form C when converting an XML document to the UCS character domain from any encoding that is not UCS-based.
We RECOMMEND that externally specified canonicalization algorithms do the same. (Note, there can be ambiguities in converting existing charsets to Unicode, for an example see the XML Japanese Profile Note [ XML-Japanese ].)
This specification REQUIRES implementation of Canonical XML 1.0 [ XML-C14N ], Canonical XML 1.1 [ XML-C14N11 ]] and Exclusive XML Canonicalization [ XML-EXC-C14N ]. We RECOMMEND that applications that generate signatures choose Canonical XML 1.1 [ XML-C14N11 ] when inclusive canonicalization is desired.
Note : Canonical XML 1.0 [ XML-C14N ] and Canonical XML 1.1 [ XML-C14N11 ] specify a standard serialization of XML that, when applied to a subdocument, includes the subdocument's ancestor context including all of the namespace declarations and some attributes in the 'xml:' namespace. However, some applications require a method which, to the extent practical, excludes unused ancestor context from a canonicalized subdocument. The Exclusive XML Canonicalization Recommendation [ XML-EXC-C14N ] may be used to address requirements resulting from scenarios where a subdocument is moved between contexts.
An example of an XML canonicalization element is:
<CanonicalizationMethod Algorithm = "
http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
The normative specification of Canonical XML1.0 is [ XML-C14N ]. The algorithm is capable of taking as input either an octet stream or an XPath node-set (or sufficiently functional alternative). The algorithm produces an octet stream as output. Canonical XML is easily parameterized (via an additional URI) to omit or retain comments.
The normative specification of Canonical XML 1.1 is [ XML-C14N11 ]. The algorithm is capable of taking as input either an octet stream or an XPath node-set (or sufficiently functional alternative). The algorithm produces an octet stream as output. Canonical XML 1.1 is easily parameterized (via an additional URI) to omit or retain comments.
The normative specification of Exclusive XML Canonicalization 1.0 is [XML-EXC-C14N]].
Transform
Algorithms
A
Transform
algorithm
has
a
single
implicit
parameter:
an
octet
stream
from
the
Reference
or
the
output
of
an
earlier
Transform
.
For implementation requirements, please see section 3.3 Compatibility Mode Conformance . Application developers are strongly encouraged to support all transforms that are listed as recommended unless the application environment has resource constraints that would make such support impractical. Compliance with this recommendation will maximize application interoperability and libraries should be available to enable support of these transforms in applications without extensive development.
Any
canonicalization
algorithm
that
can
be
used
for
CanonicalizationMethod
(such
as
those
in
section
B.6
"Compatibility
Mode"
Canonicalization
Algorithms
)
can
be
used
as
a
Transform
.
The
normative
specification
for
base64
decoding
transforms
is
[
RFC2045
].
The
base64
Transform
element
has
no
content.
The
input
is
decoded
by
the
algorithms.
This
transform
is
useful
if
an
application
needs
to
sign
the
raw
data
associated
with
the
encoded
content
of
an
element.
This
transform
accepts
either
an
octet-stream
or
a
node-set
as
input.
If
an
octet-string
is
given
as
input,
then
this
octet-stream
is
processed
directly.
If
an
XPath
node-set
(or
sufficiently
functional
alternative)
is
given
as
input,
then
it
is
converted
to
an
octet
stream
by
performing
operations
logically
equivalent
to
1)
applying
an
XPath
transform
with
expression
self::text()
,
then
2)
taking
the
string-value
of
the
node-set.
Thus,
if
an
XML
element
is
identified
by
a
shortname
XPointer
in
the
Reference
URI,
and
its
content
consists
solely
of
base64
encoded
character
data,
then
this
transform
automatically
strips
away
the
start
and
end
tags
of
the
identified
element
and
any
of
its
descendant
elements
as
well
as
any
descendant
comments
and
processing
instructions.
The
output
of
this
transform
is
an
octet
stream.
The
normative
specification
for
XPath
expression
evaluation
is
[
XPATH
].
The
XPath
expression
to
be
evaluated
appears
as
the
character
content
of
a
transform
parameter
child
element
named
XPath
.
The input required by this transform is an XPath node-set or an octet-stream. Note that if the actual input is an XPath node-set resulting from a null URI or shortname XPointer dereference, then comment nodes will have been omitted. If the actual input is an octet stream, then the application must convert the octet stream to an XPath node-set suitable for use by Canonical XML with Comments. (A subsequent application of the required Canonical XML algorithm would strip away these comments.) In other words, the input node-set should be equivalent to the one that would be created by the following process:
(//.
|
//@*
|
//namespace::*)
The evaluation of this expression includes all of the document's nodes (including comments) in the node-set representing the octet stream.
The
transform
output
is
always
an
XPath
node-set.
The
XPath
expression
appearing
in
the
XPath
parameter
is
evaluated
once
for
each
node
in
the
input
node-set.
The
result
is
converted
to
a
boolean.
If
the
boolean
is
true,
then
the
node
is
included
in
the
output
node-set.
If
the
boolean
is
false,
then
the
node
is
omitted
from
the
output
node-set.
Note:
Even
if
the
input
node-set
has
had
comments
removed,
the
comment
nodes
still
exist
in
the
underlying
parse
tree
and
can
separate
text
nodes.
For
example,
the
markup
<e>Hello,
<!--
comment
-->world!</e>
contains
two
text
nodes.
Therefore,
the
expression
self::text()[string()="Hello,
world!"]
would
fail.
Should
this
problem
arise
in
the
application,
it
can
be
solved
by
either
canonicalizing
the
document
before
the
XPath
transform
to
physically
remove
the
comments
or
by
matching
the
node
based
on
the
parent
element's
string
value
(e.g.
by
using
the
expression
self::text()[string(parent::e)="Hello,
world!"]
).
The primary purpose of this transform is to ensure that only specifically defined changes to the input XML document are permitted after the signature is affixed. This is done by omitting precisely those nodes that are allowed to change once the signature is affixed, and including all other input nodes in the output. It is the responsibility of the XPath expression author to include all nodes whose change could affect the interpretation of the transform output in the application context.
Note that the XML-Signature XPath Filter 2.0 Recommendation [ XMLDSIG-XPATH-FILTER2 ] may be used for this purpose. That recommendation defines an XPath transform that permits the easy specification of subtree selection and omission that can be efficiently implemented.
An important scenario would be a document requiring two enveloped signatures. Each signature must omit itself from its own digest calculations, but it is also necessary to exclude the second signature element from the digest calculations of the first signature so that adding the second signature does not break the first signature.
The XPath transform establishes the following evaluation context for each node of the input node-set:
As
a
result
of
the
context
node
setting,
the
XPath
expressions
appearing
in
this
transform
will
be
quite
similar
to
those
used
in
used
in
[
XSLT
],
except
that
the
size
and
position
are
always
1
to
reflect
the
fact
that
the
transform
is
automatically
visiting
every
node
(in
XSLT,
one
recursively
calls
the
command
apply-templates
to
visit
the
nodes
of
the
input
tree).
The
function
here()
is
defined
as
follows:
The here function returns a node-set containing the attribute or processing instruction node or the parent element of the text node that directly bears the XPath expression. This expression results in an error if the containing XPath expression does not appear in the same XML document against which the XPath expression is being evaluated.
As
an
example,
consider
creating
an
enveloped
signature
(a
Signature
element
that
is
a
descendant
of
an
element
being
signed).
Although
the
signed
content
should
not
be
changed
after
signing,
the
elements
within
the
Signature
element
are
changing
(e.g.
the
digest
value
must
be
put
inside
the
DigestValue
and
the
SignatureValue
must
be
subsequently
calculated).
One
way
to
prevent
these
changes
from
invalidating
the
digest
value
in
DigestValue
is
to
add
an
XPath
Transform
that
omits
all
Signature
elements
and
their
descendants.
For
example,
<Document> ... <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> <SignedInfo> ... <Reference URI=""> <Transforms> <Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"> <XPath xmlns:dsig="&dsig;"> not(ancestor-or-self::dsig:Signature) </XPath> </Transform> </Transforms> <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <DigestValue></DigestValue> </Reference> </SignedInfo> <SignatureValue></SignatureValue> </Signature> ... </Document>
Due
to
the
null
Reference
URI
in
this
example,
the
XPath
transform
input
node-set
contains
all
nodes
in
the
entire
parse
tree
starting
at
the
root
node
(except
the
comment
nodes).
For
each
node
in
this
node-set,
the
node
is
included
in
the
output
node-set
except
if
the
node
or
one
of
its
ancestors
has
a
tag
of
Signature
that
is
in
the
namespace
given
by
the
replacement
text
for
the
entity
&dsig;
.
A
more
elegant
solution
uses
the
here
function
to
omit
only
the
Signature
containing
the
XPath
Transform,
thus
allowing
enveloped
signatures
to
sign
other
signatures.
In
the
example
above,
use
the
XPath
element:
<XPath xmlns:dsig="&dsig;"> count(ancestor-or-self::dsig:Signature | here()/ancestor::dsig:Signature[1]) > count(ancestor-or-self::dsig:Signature) </XPath>
Since
the
XPath
equality
operator
converts
node
sets
to
string
values
before
comparison,
we
must
instead
use
the
XPath
union
operator
(|).
For
each
node
of
the
document,
the
predicate
expression
is
true
if
and
only
if
the
node-set
containing
the
node
and
its
Signature
element
ancestors
does
not
include
the
enveloped
Signature
element
containing
the
XPath
expression
(the
union
does
not
produce
a
larger
set
if
the
enveloped
Signature
element
is
in
the
node-set
given
by
ancestor-or-self::Signature
).
An
enveloped
signature
transform
T
removes
the
whole
Signature
element
containing
T
from
the
digest
calculation
of
the
Reference
element
containing
T
.
The
entire
string
of
characters
used
by
an
XML
processor
to
match
the
Signature
with
the
XML
production
element
is
removed.
The
output
of
the
transform
is
equivalent
to
the
output
that
would
result
from
replacing
T
with
an
XPath
transform
containing
the
following
XPath
parameter
element:
<XPath xmlns:dsig="&dsig;"> count(ancestor-or-self::dsig:Signature | here()/ancestor::dsig:Signature[1]) > count(ancestor-or-self::dsig:Signature)</XPath>
The input and output requirements of this transform are identical to those of the XPath transform, but may only be applied to a node-set from its parent XML document. Note that it is not necessary to use an XPath expression evaluator to create this transform. However, this transform must produce output in exactly the same manner as the XPath transform parameterized by the XPath expression above.
The
normative
specification
for
XSL
Transformations
is
[
XSLT
].
Specification
of
a
namespace-qualified
stylesheet
element,
which
must
be
the
sole
child
of
the
Transform
element,
indicates
that
the
specified
style
sheet
should
be
used.
Whether
this
instantiates
in-line
processing
of
local
XSLT
declarations
within
the
resource
is
determined
by
the
XSLT
processing
model;
the
ordered
application
of
multiple
stylesheet
may
require
multiple
Transforms
.
No
special
provision
is
made
for
the
identification
of
a
remote
stylesheet
at
a
given
URI
because
it
can
be
communicated
via
an
xsl:include
or
xsl:import
within
the
stylesheet
child
of
the
Transform
.
This transform requires an octet stream as input.
The output of this transform is an octet stream. The processing rules for the XSL style sheet [ XSL10 ] or transform element are stated in the XSLT specification [ XSLT ].
We
RECOMMEND
that
XSLT
transform
authors
use
an
output
method
of
xml
for
XML
and
HTML.
As
XSLT
implementations
do
not
produce
consistent
serializations
of
their
output,
we
further
RECOMMEND
inserting
a
transform
after
the
XSLT
transform
to
canonicalize
the
output.
These
steps
will
help
to
ensure
interoperability
of
the
resulting
signatures
among
applications
that
support
the
XSLT
transform.
Note
that
if
the
output
is
actually
HTML,
then
the
result
of
these
steps
is
logically
equivalent
[
XHTML10
].
Dated references below are to the latest known or appropriate edition of the referenced work. The referenced works may be subject to revision, and conformant implementations may follow, and are encouraged to investigate the appropriateness of following, some or all more recent editions or replacements of the works cited. It is in each case implementation-defined which editions are supported.