Please refer to the errata for this document, which may include some normative corrections.
The English version of this specification is the only normative version. Non-normative translations may also be available.
Copyright © 2013 W3C ® ( MIT , ERCIM , Keio , Beihang ), All Rights Reserved. W3C liability , trademark and document use rules apply.
This
document
outlines
proposed
standard
XML
Signature
Properties
syntax
and
the
syntax,
processing
rules
and
an
associated
namespace
for
these
properties.
The
intent
is
these
properties
to
be
used
in
XML
Signatures.
These
can
be
composed
with
any
version
of
XML
Signature
using
the
XML
SignatureProperties
element.
These
properties
are
intended
to
meet
code
signing
requirements.
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/.
There
This
document
has
been
reviewed
by
W3C
Members,
by
software
developers,
and
by
other
W3C
groups
and
interested
parties,
and
is
no
previous
endorsed
by
the
Director
as
a
W3C
Recommendation
of
XML
Signature
Properties.
Please
review
differences
between
Recommendation.
It
is
a
stable
document
and
may
be
used
as
reference
material
or
cited
from
another
document.
W3C
's
role
in
making
the
previous
Candidate
Recommendation
is
to
draw
attention
to
the
specification
and
this
Proposed
Recommendation
.
to
promote
its
widespread
deployment.
This
enhances
the
functionality
and
interoperability
of
the
Web.
Interoperability
testing
was
completed
by
the
W3C
Web
Applications
Working
Group
with
four
implementations
for
all
features
as
part
of
XML
Digital
Signatures
for
Widgets
interoperability
testing.
The
following
Implementation
Report
is
available.
A
diff
document
showing
changes
have
been
made
to
this
specification
since
the
previous
CR
publication
:
PR
draft
is
available.
This
document
was
published
by
the
XML
Security
Working
Group
as
a
Proposed
Recommendation.
This
document
is
intended
to
become
a
W3C
Recommendation.
The
W3C
Membership
and
other
interested
parties
are
invited
If
you
wish
to
review
the
document
and
send
make
comments
regarding
this
document,
please
send
them
to
public-xmlsec@w3.org
(
subscribe
,
archives
)
through
25
February
2013.
Advisory
Committee
Representatives
should
consult
their
WBS
questionnaires
.
Note
that
substantive
technical
).
All
comments
were
expected
during
the
Last
Call
review
period
that
ended
18
March
2010.
Please
see
the
Working
Group's
implementation
report
.
Publication
as
a
Proposed
Recommendation
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.
are
welcome.
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 .
The SignatureProperties element defined by XML Signature [ XMLDSIG-CORE1 ] offers a means to associate property values with an XML Signature. This document defines specific properties that may be used by various applications of XML Signature, without requiring those applications to define such properties on a per case basis. This document defines how these properties are to be specified and processed when used but does not require their use - specifications that reference this document may or may not require their use.
The properties defined in this document are not a breaking change to XML Signature, but warrant a new namespace for the properties themselves so that they can be used in various versions of XML Signature.
The XAdES specification defines signature property formats for advanced electronic signatures that remain valid over long periods, are compliant with the European Directive and incorporate additional useful information in common uses cases [ XADES ].
This specification provides a normative XML Schema [ XMLSCHEMA-1 ], [ XMLSCHEMA-2 ]. The full normative grammar is defined by the XSD schema and the normative text in this specification. The standalone XSD schema file is authoritative in case there is any disagreement between it and the XSD schema portions in this specification.
The
key
words
"
must
MUST
",
"
must
not
MUST
NOT
",
"
required
REQUIRED
",
"
shall
SHALL
",
"
shall
not
SHALL
NOT
",
"
should
SHOULD
",
"
should
not
SHOULD
NOT
",
"
recommended
RECOMMENDED
",
"
may
MAY
",
and
"
optional
OPTIONAL
"
in
this
specification
are
to
be
interpreted
as
described
in
[
RFC2119
].
"They
mustMUST 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, these capitalized keywords are used 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. For instance, an XML attribute might be described as being "optional."
No
provision
is
made
for
an
explicit
version
number
in
this
syntax.
If
a
future
version
is
needed,
it
will
use
a
different
namespace.
The
XML
namespace
[
XML-NAMES
]
URI
that
must
MUST
be
used
by
implementations
of
this
(dated)
specification
is:
xmlns dsp="http://www.w3.org/2009/xmldsig-properties"
This
namespace
is
also
used
as
the
prefix
for
identifiers
defined
by
this
specification.
While
applications
must
MUST
support
XML
and
XML
namespaces,
the
use
of
internal
entities
[
XML10
]
or
our
dsp
XML
namespace
prefix
and
defaulting/scoping
conventions
are
optional
OPTIONAL
;
use
these
facilities
to
provide
compact
and
readable
examples.
This specification uses Uniform Resource Identifiers [ URI ] to identify resources, algorithms, and semantics. The URI in the namespace declaration above is also used as a prefix for URIs under the control of this specification.
This document does not change the namespace URI associated with XML Signature itself.
All material in this document is Normative except for examples and sections marked as non-normative.
Use
of
any
or
all
of
these
Signature
Properties
in
an
XML
Signature
is
optional
OPTIONAL
and
nothing
precludes
the
use
of
additional
properties
defined
elsewhere.
Common Signature Properties are properties defined in this specification and identified by the namespace defined in this document.
The full normative grammar is defined by the XSD schema and the normative text in this specification. The standalone XSD schema file is authoritative in case there is any disagreement between it and the XSD schema portions in this specification.
This section is non-normative.
This section is non-normative.
A developer (author) produces code that is delivered to users by a distributor (mobile operator). The code package contains an XML Signature and this should be validated upon code installation to provide integrity for the package. The signature delivered with the package from the distributor may change upon later installations for various reasons, such as the inclusion of more timely revocation information, so signatures should have an expiration. One goal is not to depend an X509 certificate expiration for this functionality, since that certificate may have a longer lifetime.
This case can introduce requirements for an expiration of a signature as well as identifying the role of a signer (developer or distributor), as well as a possible profile of the general signature standard for that specific use case (such as restricting algorithms etc).
There are specific requirements associated with this use case:
Specify any additional constraints on the use of XML Signature, referencing an appropriate profile by URI. This might limit algorithms, for example.
Define an expiration with a signature, enabling a validator to determine that the signature should no longer validate after a given time.
State the role of the signature creator, e.g. author, distributor etc.
The Signature Properties defined in this specification are intended to be used with XML Signature [ XMLDSIG-CORE1 ].
When
a
Signature
Property
element
defined
by
this
specification
is
used
within
an
XML
Signature
it
must
MUST
be
contained
within
a
ds:SignatureProperty
element.
This
ds:SignatureProperty
element
must
MUST
be
contained
within
a
ds:SignatureProperties
element.
The
ds:SignatureProperties
element
must
MUST
be
contained
within
a
ds:Object
element
within
the
ds:Signature
element.
This section includes schema definitions and processing rules for Common Signature Properties .
This
section
defines
a
number
of
signature
properties
that
are
expected
to
be
commonly
used
in
profiles.
For
each
property,
an
intended
processing
model
is
suggested.
However,
the
details
of
processing
each
of
these
properties
will
depend
upon
individual
application
scenarios,
and
must
MUST
be
specified
in
any
profile
that
makes
use
of
the
properties
defined
in
this
document.
The Profile Property specifies a URI to be associated with the Signature instance to identify a Profile specification that details how the XML Signature is to be used. This profile may restrict the choice of algorithms, for example, as well as requiring certain Common Signature Properties and/or other properties in the signature.
The element has no content, but specifies a URI attribute that is required.
<element name="Profile" type="dsp:ProfileType"/> <complexType name="ProfileType"> <attribute name="URI" type="anyURI"/> </complexType>
Upon
Signature
generation,
if
this
property
is
used,
the
URI
attribute
value
must
MUST
be
set
to
a
value
that
can
be
understood
by
the
relying
party.
Applications are expected to use this property to verify an assertion that a signature is meant to fulfill a specific profile. Validation behavior is application-specific.
Profiles
must
MUST
specify
what
application
behavior
is
expected
in
case
an
unknown
profile
URI
is
encountered.
Profiles
must
MUST
specify
whether
profile
URIs
defined
by
them
can
coexist
with
other
instances
of
the
profile
property
element.
The Role Property allows a URI to be associated with the signature to specify an application specific role for the signature, implying application specific processing steps related to the signature.
An example might be to indicate that the signer of code is the author or the distributor of that code.
The element has no content, but specifies a URI attribute that is required.
<element name="Role" type="dsp:RoleType"/> <complexType name="RoleType"> <attribute name="URI" type="anyURI"/> </complexType>
Upon
Signature
generation,
if
this
property
is
used,
the
URI
attribute
value
must
MUST
be
set
to
a
value
that
can
be
understood
by
the
relying
party.
Applications
are
expected
to
use
this
property
to
identify
a
specific
role
for
a
signature
(e.g.,
author
or
distributor
signed).
An
unexpected
role
URI
will
frequently
be
reason
for
applications
to
deem
a
signature
invalid.
Profiles
must
MUST
specify
what
application
behavior
is
expected
in
case
an
unknown
role
URI
is
encountered,
or
when
several
role
properties
exist
on
a
single
signature.
The Identifier Property is intended to enable use cases where a unique identifier needs to be associated with the signature, such as to enable signature management.
<element name="Identifier" type="string"/>
Identifier
string
values
must
MUST
be
unique
for
each
signature
from
a
given
signer
and
should
SHOULD
be
unique
across
all
signers.
Upon Signature generation, if this property is used, the value is set to a unique value to be associated with the signature for a particular signer.
Applications are expected to use this property to identify the signature.
Profiles
must
MUST
specify
details
of
the
identifier
property
value
creation
and
interpretation.
If
multiple
instances
of
this
property
are
found
on
a
single
signature,
then
applications
must
not
MUST
NOT
deem
any
of
these
properties
valid.
Valid XML Schema instance based on the XML Schema [ XMLSCHEMA-1 ], [ XMLSCHEMA-2 ].
This schema instance binds together the XML Signature Core XML Schema instance, the XML Signature 1.1 XML Schema instance and the XML Signature Properties XML Schema instance.
A cryptographically fabricated XML Signature Properties example that validates under the schema.
This section is non-normative.
Non-normative RELAX NG schema [ RELAXNG-SCHEMA ] information is available in a separate document [ XMLSEC-RELAXNG ].
The
Working
Group
thanks
Mark
Priestley,
Vodafone,
Priestley
and
Marcos
Caceres,
Opera
Software,
Caceres
of
the
W3C
Web
Applications
Working
Group
for
requirements
discussions
related
to
widget
signing,
and
thanks
Makoto
Murata
for
assistance
with
the
RELAX
NG
schema.
Contributions 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, Brian LaMacchia, Konrad Lanz, Hal Lockhart, Cynthia Martin, Rob Miller, Sean Mullan, Shivaram Mysore, Magnus Nyström, Bruce Rich, Thomas Roessler, Ed Simon, Chris Solc, John Wray, Kelvin Yiu.
The Working Group also acknowledges the interoperability testing performed by members of the W3C Web Applications Working Group .
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.