XML Signature Properties

W3C Editor's Draft 24 January 2013

This version:
Latest published version:
Latest editor's draft:
Frederick Hirsch


This document outlines proposed standard XML Signature Properties syntax and processing rules and an associated namespace for these properties. The intent is these can be composed with any version of XML Signature using the XML SignatureProperties element. These properties are intended to meet code signing requirements.

Status of This Document

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 is no previous W3C Recommendation of XML Signature Properties. Please review differences between the previous Candidate Recommendation and this Proposed Recommendation.

The following changes have been made to this specification since the previous CR publication:

This document was published by the XML Security Working Group as an Editor's Draft. 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 an Editor's 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. 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.

Table of Contents

1. Introduction

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].

2. Editorial and Conformance Conventions

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 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, 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."

3. Versions, Namespaces and Identifiers

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 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 support XML and XML namespaces, the use of internal entities [XML10] or our dsp XML namespace prefix and defaulting/scoping conventions are 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.

4. Normative Material and Compliance

4.1 Normative Material

All material in this document is Normative except for examples and sections marked as non-normative.

4.2 Compliance

Use of any or all of these Signature Properties in an XML Signature is 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.

5. Usage scenarios and Requirements

This section is non-normative.

5.1 Mobile Code Signing Scenario

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).

5.2 Mobile Code Signing Requirements

There are specific requirements associated with this use case:

  1. Specify any additional constraints on the use of XML Signature, referencing an appropriate profile by URI. This might limit algorithms, for example.

  2. Define an expiration with a signature, enabling a validator to determine that the signature should no longer validate after a given time.

  3. State the role of the signature creator, e.g. author, distributor etc.

6. Signature Properties Placement

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 be contained within a ds:SignatureProperty element.

This ds:SignatureProperty element must be contained within a ds:SignatureProperties element.

The ds:SignatureProperties element must be contained within a ds:Object element within the ds:Signature element.

7. Signature Properties

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 be specified in any profile that makes use of the properties defined in this document.

7.1 Profile Property

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"/>

7.1.1 Generation

Upon Signature generation, if this property is used, the URI attribute value must be set to a value that can be understood by the relying party.

7.1.2 Validation

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 specify what application behavior is expected in case an unknown profile URI is encountered.

Profiles must specify whether profile URIs defined by them can coexist with other instances of the profile property element.

7.2 Role Property

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"/>

7.2.1 Generation

Upon Signature generation, if this property is used, the URI attribute value must be set to a value that can be understood by the relying party.

7.2.2 Validation

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 specify what application behavior is expected in case an unknown role URI is encountered, or when several role properties exist on a single signature.

7.3 Identifier Property

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 be unique for each signature from a given signer and should be unique across all signers.

7.3.1 Generation

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.

7.3.2 Validation

Applications are expected to use this property to identify the signature.

Profiles 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 deem any of these properties valid.

8. Schema

8.1 XSD Schema and Valid Example

Signature Properties XSD Schema Instance

Valid XML Schema instance based on the XML Schema [XMLSCHEMA-1], [XMLSCHEMA-2].

Signature Properties 1.1 Schema Driver

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.

XML Security Signature Properties Example

A cryptographically fabricated XML Signature Properties example that validates under the schema.

8.2 RNG Schema

This section is non-normative.

Non-normative RELAX NG schema [RELAXNG-SCHEMA] information is available in a separate document [XMLSEC-RELAXNG].

9. Acknowledgments

The Working Group thanks Mark Priestley, Vodafone, and Marcos Caceres, Opera Software, 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.

A. References

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.

A.1 Normative references

S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Internet RFC 2119. URL: http://www.ietf.org/rfc/rfc2119.txt
T. Berners-Lee; R. Fielding; L. Masinter. Uniform Resource Identifiers (URI): generic syntax. January 2005. Internet RFC 3986. URL: http://www.ietf.org/rfc/rfc3986.txt
Richard Tobin et al. Namespaces in XML 1.0 (Third Edition). 8 December 2009. W3C Recommendation. URL: http://www.w3.org/TR/2009/REC-xml-names-20091208/
D. Eastlake, J. Reagle, D. Solo, F. Hirsch, T. Roessler, K. Yiu. XML Signature Syntax and Processing Version 1.1. 24 January 2013. W3C Proposed Recommendation. (Work in progress) URL: http://www.w3.org/TR/2013/PR-xmldsig-core1-20130124/
Henry S. Thompson et al. XML Schema Part 1: Structures Second Edition. 28 October 2004. W3C Recommendation. URL: http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/
Paul V. Biron; Ashok Malhotra. XML Schema Part 2: Datatypes Second Edition. 28 October 2004. W3C Recommendation. URL: http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/

A.2 Informative references

Information technology -- Document Schema Definition Language (DSDL) -- Part 2: Regular-grammar-based validation -- RELAX NG. ISO/IEC 19757-2:2008. URL: http://standards.iso.org/ittf/PubliclyAvailableStandards/c052348_ISO_IEC_19757-2_2008(E).zip
XML Advanced Electronic Signatures (XAdES). ETSI TS 101 903 V1.4.1 (2009-06) URL: http://www.etsi.org/deliver/etsi_ts/101900_101999/101903/01.04.01_60/ts_101903v010401p.pdf
C. M. Sperberg-McQueen et al. Extensible Markup Language (XML) 1.0 (Fifth Edition). 26 November 2008. W3C Recommendation. URL: http://www.w3.org/TR/2008/REC-xml-20081126/
Makoto Murata; Frederick Hirsch. XML Security RELAX NG Schemas. 24 January 2013. W3C Working Group Note. URL: http://www.w3.org/TR/2013/NOTE-xmlsec-rngschema-20130124/