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 Working Draft of "XML Security Use Cases and
Requirements." This document is expected to be further
updated based on both Working Group input and
public comments. The Working Group
anticipates to eventually publish a
stabilized version of this document as a W3C Working Group Note.
The use cases and requirements in
this document are expected to
help guide the XML Security
Working Group's development of a version 1.1
of XML Signature. Information about requirements for a version 2.0
of XML Signature have been moved into a separate document XML
Security 2.0 Requirements .
This document was
by the XML Security Working Group
. Please send comments
about this document to firstname.lastname@example.org (with public archive
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 document was produced by a group operating under the 5 February 2004 W3C Patent Policy . The group does not expect this document to become a W3C Recommendation. 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
XML Encryption [XMLENC]
and Canonical XML 1.1 [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.
design of revisions to
the XML Security specifications.
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
as well as general principles from 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
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
in order to maintain interoperability with
existing and prospective XML specifications.
XML Signatures should themselves be self-describing first class
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
Several open specifications make use of derived keys, e.g. RSA
Laboratories' PKCS #5 v2.0
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
Contrary to the situation in the ASN.1-based world (e.g. S/MIME
), 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 [PKCS#5]
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.
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
Ws-Trust Version 1.3
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.
[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
<wsc:SecurityContextToken> ." The derived
key token does not support references using key identifiers or key
names. All references
MUST use an
ID (to a wsu:Id attribute) or a URI reference to the
<wsc:Identifier> element in the Security Context
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.
Evaluating the existing specifications against the requirements gives the following result:
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
R1: N/A (WS-Trust does not define a derived key type per se; only a method to derive keys)
R3: Meets (Through use of URI to identify method and extensibility)
R5: Meets (Choice of STS on how to identify key)
R1: N/A (WS-SecurityPolicy does not define a derived key type)
R3: Meets (Through the use of URIs to identify key derivation methods and schema extensibility)
R2: Does not meet.
R3: Meets (may use the
to carry parameters for other key derivation methods.
R5: Does not meet as referencing can only be done to a
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
Example: 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><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 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
meet 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
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
only required to identify particular key derivation methods. Since
URIs are used for this (the
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
when there already is a shared key between the STS and a token
requestor. 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
<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
<Nonce> elements) although it does not
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
In order to meet the principle of "Secure" and "Pragmatic", new algorithm requirements should be met.
SHA256 be required.
SHA384 and SHA512 optional.
HMAC-SHA384 and HMAC-SHA512 optional.
RSAwithSHA384, RSAwithSHA512 optional.
In order to discourage the use of DSAwithSHA1 but to continue to enable interoperability, the following algorithm changes are requirements;
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
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:
ECDSAwithSHA1, ECDSAwithSHA384, ECDSAwithSHA512 optional.
Define ECKeyValue element to enable interoperable exchange of EC public key values in XML Signature context.
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
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
[XSD] ). 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
Example: Definition of Y in ECDSAKeyValue<!ELEMENT Y EMPTY> <!ATTLIST Y Value CDATA #REQUIRED>
However, DSAKeyValue defines Y as follows:
Definition of Y in DSAKeyValue
Example: Definition ofY 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,
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
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.
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.
Enemy of Security: Position Paper for W3C Workshop on Next Steps
for XML Signature and
XML Encryption , Brad Hill, 25-26 September