Copyright © 2013 W3C ® ( MIT , ERCIM , Keio , Beihang ), All Rights Reserved. W3C liability , trademark and document use rules apply.
This Note summarizes scenarios, design decisions, and requirements for the XML Signature and Canonical XML specifications, to guide ongoing W3C work to revise these specifications.
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/.
Changes
since
the
previous
publication
include
reformatting
of
some
material
and
editorial
corrections.
updates
to
the
references
(
diff
).
This document was published by the XML Security Working Group as a Working Group Note. If you wish to make comments regarding this document, please send them to public-xmlsec@w3.org ( subscribe , archives ). All comments are welcome.
Publication as a Working Group Note 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 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 .
This use case and requirements document is intended to summarize use cases and requirements driving revisions to XML Signature 2nd Edition [ XMLDSIG-CORE ], XML Encryption [ XMLENC-CORE ], and Canonical XML 1.1 [ XML-C14N11 ]. It is not intended to define all possible use cases for these Recommendations, but rather to provide rationale for decisions leading to XML Signature 1.1, XML Encryption 1.1, XML Signature Properties and XML Security Generic Hybrid Ciphers.
This document outlines general principles and use cases leading to requirements and offers some design options. It elaborates on principles and updates requirements expressed for the original XML Security work including original requirements documents (e.g. [ XML-CANONICAL-REQ ], and [ XMLDSIG-REQUIREMENTS ]). This document also reflects material from a W3C workshop on next steps for XML Security [ XMLSEC-NEXTSTEPS-2007 ] and position papers associated with the workshop, including [ XMLDSIG-COMPLEXITY ], [ XMLDSIG-SEMANTICS ], and [ XMLDSIG-THOMPSON ].
Design options were documented early on to provide a starting point with the expectation that specifications developed to meet the requirements could subsequently differ in design choices.Thus the design choices in this document should be viewed as historical information.
The following design principles will be used to guide further development of XML Security, including XML Signature, XML Encryption and Canonical XML. These principles are intended to encourage consistent design decisions, to provide insight into design rationale and to anchor discussions on requirements and design. This list includes items from the original requirements for XML Signature [ XMLDSIG-REQUIREMENTS ] as well as general principles from EXI [ EXI ]. Listed in alphabetical order:
Backward compatibility should not be broken unnecessarily. Versioning should be clearly considered. Consideration must be given, for example, for interoperability with the First and Second Editions of XML Signature [ XMLDSIG-CORE ].
XML Security must be consistent with the Web Architecture [ WEBARCH ].
XML Security should enable efficient implementations, in order to remove barriers to adoption and use.
One of primary objectives of XML Signature is to support a wide variety of use cases requiring digital signatures, including situations requiring multiple signatures, counter-signatures, and signatures including multiple items to be included in a signature. Extensibility should be possible, but by default options should be constrained when the flexibility is not needed.
To reach the broadest set of applications, reduce the security threat footprint and improve efficiency, simple, elegant approaches are preferred to large, analytical or complex ones.
Recognize pragmatic issues, including recognizing that software might be implemented in layers, with a security layer independent of an application layer.
Existing open standards should be reused where possible, as long as other principles can be met.
XML Security should adhere to security best practices, and minimize the opportunities for threats based on XML Security mechanisms.
XML Security must integrate well with existing XML technologies, be compatible with the XML Information Set [ XML-INFOSET ], in order to maintain interoperability with existing and prospective XML specifications.
XML Signatures should themselves be self-describing first class XML objects [ XMLDSIG-REQUIREMENTS ]. This means that XML Signatures can be referenced via URI and used in other operations. For example, an XML Signature may be signed or encrypted, or referred to in a statement (such as an RDF statement).
This section outlines the motivation, requirements and design considerations for XML Security 1.1.
Widgets may require signing for integrity protection and source authentication. This signing of a Widget package may be provided using XML Signature.
Provide the ability to sign and verify a widget package using XML Signature. Enable the use of SHA-256 to support sufficient security. Support the use of properties in a XML Signature, including Profile, Role, and Identifier properties to enable interoperable interpretation of signatures. See the Widget Signature specification for a summary of requirements [ WIDGETS-DIGSIG ].
Define generic widget properties. See XML Signature Properties [ XMLDSIG-PROPERTIES ].
Several open specifications make use of derived keys, e.g. RSA Laboratories' PKCS #5 v2.0 [ PKCS5 ] and OASIS' WS-SecureConversation Version 1.3 [ WS-SECURECONVERSATION13 ]. These derived keys are used for a variety of purposes including encryption and message authentication, and the purpose of key derivation itself is typically a combination of a desire to expand a given, but limited, set of key material and prudent security practices of limiting use (exposure) of such key material.
Contrary to the situation in the ASN.1-based world (e.g. S/MIME [ SMIME ]), there is currently a lack of general support in the core XML Security specifications, XML Signature and XML Encryption, for derived keys. Amendment 1 of the aforementioned PKCS #5 v2.0 Amendment 1 [ PKCS5 ] adds support for derived keys only in the context of password-based cryptography. Other XML-based open specifications have similar limitations (see below). This means that an originator of an XML document or message cannot generally make use of key derivation in a standardized manner when performing cryptographic operations on that document.
This section outlines the use of derived keys with Web Services specifications related to Web Services Security [ WS-SECURITY11 ].
This specification [ WSS-USERNAME11 ] describes a key derivation technique for passwords using salt and iteration count (PKCS #5 PBKDF1). It does not allow use of PBKDF2, which is the recommended method to derive keys from passwords in PKCS #5 v2.0. Initial key material cannot be referenced other than with wsu:Id. The key length will always be 160 bits.
Ws-Trust Version 1.3 [ WS-TRUST13 ] describes key derivation through a combination of entropies from both parties. The key is never sent on the wire. The key is never referenced directly (but further key material is derived from it). WS-Trust provides one specific method to derive keys which builds on the P_hash (P_SHA-1) function from TLS.
WS-SecurityPolicy Version 1.2 [ WS-SECURITYPOLICY12 ] really only specifies whether derived keys shall be used or not but may also specify the algorithm to derive keys. The specification also identifies when derived key tokens shall appear in message headers (header layout). WS-SecurityPolicy relies on WS-SecureConversation for the definition of derived keys, key derivation methods and derived key token format.
This
specification
[
WS-SECURECONVERSATION13
]
defines
the
wsc:DerivedKeyTokenType
token
type.
The
derived
key
token
can
be
used
to
derive
keys
from
any
other
token
that
contains
keys.
The
key
derivation
algorithm
specified
builds
on
the
P_hash
(P_SHA-1)
function
from
TLS,
just
as
the
algorithm
in
the
Web
Service
Security
UsernameToken
Profile
document.
Citing
from
the
specification:
"The
<wsc:DerivedKeyToken>
element
is
used
to
indicate
that
the
key
for
a
specific
reference
is
generated
from
the
function.
This
is
so
that
explicit
security
tokens,
secrets,
or
key
material
need
not
be
exchanged
as
often."
(This
latter
seems
dubious
since
the
DerivedKeyToken
still
needs
to
be
exchanged.)
Further:
"Basically,
a
signature
or
encryption
references
a
<wsc:DerivedKeyToken>
in
the
<wsse:Security>
header
that,
in
turn,
references
the
<wsc:SecurityContextToken>
."
The
derived
key
token
does
not
support
references
using
key
identifiers
or
key
names.
All
references
must
MUST
use
an
ID
(to
a
wsu:Id
attribute)
or
a
URI
reference
to
the
<wsc:Identifier>
element
in
the
Security
Context
Token.
A derived key type shall be possible to use in those situations where existing specifications make use of ad-hoc derived keys or needs a derived key type
The motivation for this requirement is that any XML Security definition shall be generic enough that there shall be no need to continue with "point" solutions for derived keys; i.e. it shall cover existing and foreseeable uses.
A derived key type shall enable the simple use of derived keys with XML Signature or XML Encryption -using applications, and shall not require import of non- W3C developed specifications with complex security tokens.
The motivation for this is that basic use of XML Signature or XML Encryption should not require use of externally defined security tokens or other security specification elements.
An XML Security derived key type shall allow for existing methods to derive keys; i.e. it shall be possible to use already specified key derivation methods with the new derived key type.
This requirement is based on the assumptions that implementations may want to continue with already chosen key derivation schemes.
A derived key type shall allow for arbitrary derived key lengths.
A derived key type shall allow for referencing using any referencing method in use today for other key types used in XMLDsig or XMLEnc.
A derived key type shall allow for forward referencing with reference lists as recommended by WS-I BSP [ WSI-BSP10 ].
Evaluating the existing specifications against the requirements gives the following result:
UsernameToken Profile:
R1: Not met (method specified in UsernameToken profile is ad-hoc for UsernameToken specifically)
R2: Not met (method requires use of UsernameToken profile)
R3: Not met (UsernameToken profile mandates use of specified mechanism)
R4: Not met (Only accept length of 160 bits)
R5:
Not
met
(No
referencing
with
KeyName
or
KeyIdentifier
and
no
<referenceList>
element)
WS-Trust:
R1: N/A (WS-Trust does not define a derived key type per se; only a method to derive keys)
R2: N/A
R3: Meets (Through use of URI to identify method and extensibility)
R4: Meets
R5: Meets (Choice of STS on how to identify key)
WS-SecurityPolicy:
R1: N/A (WS-SecurityPolicy does not define a derived key type)
R2: N/A
R3: Meets (Through the use of URIs to identify key derivation methods and schema extensibility)
R4: Meets
R5: N/A
WS-SecureConversation:
R1: Meets
R2: Does not meet.
R3:
Meets
(may
use
the
<Properties>
element
to
carry
parameters
for
other
key
derivation
methods.
R4: Meets
R5:
Does
not
meet
as
referencing
can
only
be
done
to
a
<wsse:SecurityTokenReference>
In
this
design
option,
the
new
DerivedKeyType
is
modeled
after
the
xenc:EncryptedKeyType
.
A
*possible*
outline
of
such
a
type
could
be:
Outline of possible DerivedKeyType schema definition <element name="DerivedKey" type="xmlsec:DerivedKeyType"/> <complexType name="DerivedKeyType"> <sequence> <element name="KeyDerivationMethod" type="xmlsec:KeyDerivationMethodType" minOccurs="0"/> <element ref="xenc:ReferenceList" minOccurs="0"/> <element name="CarriedKeyName" type="string" minOccurs="0"/> </sequence> <attribute name="Id" type="ID" use="optional"/> <attribute name="Type" type="anyURI" use="optional"/> </complexType> <complexType name="KeyDerivationMethodType"> <sequence> <any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> </sequence> <attribute name="Algorithm" type="anyURI" use="required"/> </ complexType >
The proposal immediately meets requirements R2, R3 (any key derivation method may be used, including the ones specified, e.g., in WS-SecureConversation), R4 and R5. For R1 we have:
Username
Token
Profile:
As
the
UsernameToken
Profile
requires
use
of
an
existing
procedure
to
derive
keys,
the
proposal
cannot
formally
meet
requirement
R1.
However,
since
the
UsernameTokenType
is
extensible,
syntactically
the
requirement
can
be
met
since
a
<ds:DerivedKey>
element
could
be
placed
in
lieu
of
the
current
<salt>
and
<iteration>
elements.
WS-Trust:
Use
of
derived
keys
in
WS-Trust
is
_implicit_,
since
the
derived
key
is
never
sent.
The
derived
keys
may
be
referenced
by
any
available
means
in
issued
tokens
and
the
requester
is
only
required
to
identify
particular
key
derivation
methods.
Since
URIs
are
used
for
this
(the
<wst:ComputedKey>
element),
any
other
key
derivation
method
with
a
well-known
URI
may
be
used.
Specifically,
one
can
also
envision
an
STS
returning
a
proof
token
containing
a
<DerivedKey>
element
when
there
already
is
a
shared
key
between
the
STS
and
a
token
requester.
And
so,
R1
is
met.
WS-SecurityPolicy: Not affected by a new key type. R1 is met.
WS-SecureConversation:
Use
of
derived
keys
in
WS-SecureConversation
is
typically
based
on
the
establishment
of
a
session
context,
from
which
specific
keys
are
derived.
The
proposed
<xmlsec:DerivedKeyType>
type
may
be
used
in
a
similar
fashion,
although
the
interactive
nature
of
WS-SecureConversation
(exchange
of
Nonces,
Labels)
may
still
favor
use
of
the
existing
DerivedKeyToken
in
this
context.
But
as
a
counterexample,
a
party
that
wishes
to
send
data
authenticated
with
a
key
derived
from
a
key
established
in
the
session,
may
do
so
using
the
<xmlsec:DerivedKey>
element
in
the
<ds:KeyInfo>
element,
and
the
element
may
refer
to
a
SecurityContextToken
that
identifies
the
base
key.
This
would,
it
seems,
eliminate
an
absolute
need
for
a
<wsc:DerivedKeyToken>
(and
should
be
similar
in
nature
as
the
"Implied
Derived
Key"
option
in
WS-SecureConversation).
Also,
the
<wsc:DerivedKeyToken>
implies
use
of
a
particular
key
derivation
algorithm
(the
<Label>
and
<Nonce>
elements)
although
it
does
not
require
them.
In summary, WS-Trust and WS-SecurityPolicy are not directly affected by this proposal. UsernameToken profile could use the proposal if the (artificial) requirement to only use the key derivation method specified in the UsernameToken Profile document was relaxed. WS-SecureConversation comes close in establishing an alternative but the specification defines a token primarily for use in interactive sessions based on a security context and which is designed for a particular key derivation method. It also seems strange to require use of such a token in more basic XMLDsig or XMLEnc situations. Finally, the proposal seems to be able to replace the DerivedKeyToken currently used in WS-SecureConversation.
XML Signature specifies algorithm identifiers and implementation requirements for algorithms related to various aspects of signature processing, including digest and signature algorithms. The algorithms listed in XML Signature, Second Edition date from the original XML Signature Recommendation, published in 2002. Since that time there have been new algorithms introduced to address security risks associated with earlier algorithms (e.g. SHA-256 versus SHA-1), changes in patent status related to algorithms (e.g. RSA signing no longer has licensing requirements), and additional algorithms introduced to meet additional requirements (Suite B algorithms [ SUITEB ], [ ECC-ALGS ]).
In order to meet the principle of "Secure" and "Pragmatic", new algorithm requirements should be met.
In order to address concerns related to potential risks associated with SHA-1 [ SHA-1-Collisions ], the following algorithm requirements that update the SHA algorithm should be met in XML Signature 1.1 and XML Encryption 1.1:
Digest:
SHA256 be required.
SHA384 and SHA512 optional.
Mac:
HMAC-SHA256 recommended.
HMAC-SHA384 and HMAC-SHA512 optional. (Note these are Recommended in XML Signature 1.1.)
Signature:
RSAwithSHA256 required.
RSAwithSHA384, RSAwithSHA512 optional.
In order to discourage the use of DSAwithSHA1 but to continue to enable interoperability, the following algorithm changes are requirements;
Signature:
Continue to require DSAwithSHA1 for signature verification, but change DSAwithSHA1 to optional (from required) for signature generation.
In order to:
enable long term security for digital signatures (including in commercial contexts),
ensure that the XML Signature standard is cryptographically secure and makes use of the best current practices for digital signature algorithms, and
enable use of XML Signature technology in a wide variety of commercial and government applications, including those that require Suite B
The additional algorithm requirements are as follows:
Signature:
Require ECDSAwithSHA256.
ECDSAwithSHA1, ECDSAwithSHA384, ECDSAwithSHA512 optional. (Note ECDSAwithSHA1 is Discouraged in XML Signature 1.1 due to concerns with SHA-1.)
Define ECKeyValue element to enable interoperable exchange of EC public key values in XML Signature context.
Provide profile guidance for use of RFC 4050 [ RFC4050 ] when it continues to be used in XML Signature context but indicate preference for mechanism defined in XML Signature.
The last two requirements are discussed in more detail in the following design section.
RFC 4050 is an informational RFC that defines a method of representing ECDSA public keys and ECC curve parameters for use with XML Signature, but it has some issues related to XML Signature:
The RFC 4050 definition of an ECDSAKeyValue is larger than necessary.
An ECDSAKeyValue is defined by the type ECPointType, which has subelements X and Y. X and Y are defined as FieldParamsType which is an abstract type. Separate derived types are defined for prime fields, trinomial base fields, pentanomial base fields, and odd characteristic extension fields. In order to validate against the 4050 schema, one must include the type attribute from the XML schema instance namespace. This is not a significant problem but it does make the public key larger than necessary.
ECPointType definition is inconsistent with ANSI X9.62 and RFC 3279.
ECPointType is reused in the definition of the ExplicitParamsType to describe the base point of a curve. The field parameters are already included in the FieldParams element. The use of the FieldParamsType in the ECPointType definition appears to be a mistake in 4050. If you look at the ASN.1 definition for ECC public keys in RFC 3279 [ RFC3279 ] , ECPoint simply references the Point to Octet String conversion function in ANSI X9.62 (section A.5.6 in the 2005 version, section 4.3.6 in the 1998 version). The conversion functions in X9.62 are not ASN.1 specific and it appears they would be implemented as part of any ECC crypto library. It appears that RFC 4050 tried to avoid using any of the conversion functions in X9.62 but somehow mixed up the definitions between a field type and a field element.
Limitation of the decimal type in XSD
RFC 4050 defines X and Y (at least for prime and odd characteristic extension fields) as xs:nonNegativeInteger which derives from the xs:decimal primitive type. However, XSD requires implementations to support only a maximum of 18 digits (see section 3.2.3 in [ XMLSCHEMA11-2 ] ). It is possible to create an example requiring 77 and 78 digits for X and Y respectively. This means that there is no guarantee that an RFC 4050 compliant ECDSAKeyValue element will actually validate against the RFC 4050 schema.
Collision between the RFC 4050 DTD and the XMLDSIG DTD
Merging the RFC 4050 DTD into the XMLDSIG DTD is a problem due to conflicting DTD definitions. In ECDSAKeyValue, Y is defined as follows:
Definition of Y in ECDSAKeyValue <!ELEMENT Y EMPTY> <! ATTLIST Y Value CDATA #REQUIRED>
However, DSAKeyValue defines Y as follows:
Definition of Y in DSAKeyValue <! ELEMENT Y ( #PCDATA) >
ECDSAKeyValue also contains identical definition for elements SEED and P as DSAKeyValue.
It does not seem possible to scope the definition of Y under a specific element in DTD.
Because of these issues, a possible proposed solution is for XML Signature 1.1 to define a new ECPublicKey element in the ds namespace rather than attempt to reuse the RFC 4050 ECDSAPublicKey elements. This new element will be based on the ASN.1 definition ANSI X9.62 and RFC 3279. Changing the name of the element to ECPublicKey means it can be also used in XML Encryption to support ECDH. (Note, XML Signature 1.1 defined ECKeyValue instead).
To maximize interoperability with existing RFC 4050 implementations, we should also put a note in 1.1 to recommend implementations to support a profile of RFC 4050. The profile will support only named prime curves.
This section summarizes the motivation for new features designed to address known issues. (This section of the requirements document was written after the XML Signature 1.1 specification was updated in order to record the rationale for the changes.)
X509IssueSerial
The
X509IssuerSerialNumber
child
element
of
the
X509IssuerSerialType
XML
Schema
type
was
defined
to
be
an
integer
holding
an
X.509
certificate
serial
number.
XML
Schema
validators
may
not
support
integer
types
with
decimal
data
exceeding
18
decimal
digits
[
XMLSCHEMA-2
]
and
this
maximum
length
has
proven
insufficient
as
many
Certificate
Authorities
issue
certificates
with
large
random
serial
numbers
that
exceed
this
limit.
A
new
element
is
defined
in
XML
Signature
1.1
with
a
different
type
definition,
the
sig11:X509Digest
element,
and
a
warning
that
deployments
that
make
use
of
the
X509IssuerSerial
element
should
take
care
if
schema
validation
is
involved.
ds:KeyInfo
The
RetrievalMethod
is
ambiguous
about
whether
the
result
is
an
element
within
KeyInfo
or
the
KeyInfo
element
itself.
It
also
supports
the
use
of
ds:Transform
adding
complexity.
The
new
KeyInfoReference
element
removes
the
ambiguity
by
always
referencing
the
KeyInfo
element
itself.
It
also
is
simpler
in
that
it
does
not
allow
any
ds:Transform
children.
KeyValue
type
interoperability
XML
Signature
1.1
defines
XML
formats
to
convey
key
information
in
the
KeyValue
element.
There
are
scenarios
where
at
least
one
of
signer
and/or
verifier
are
not
able
to
serialize
keys
in
those
XML
formats.
The
DEREncodedKeyValue
element
has
been
added
to
XML
Signature
1.1
to
support
use
of
other
binary
encodings.
It
is
sometimes
useful
to
provide
an
OCSP
response
along
with
an
X.509
certificate.
The
OCSPResponse
element
was
added
to
X509Data
to
support
this
use
case.
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.
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.