---

Abstract

This document defines a profile of the XML Signature Syntax and Processing 1.1 specification to allow a widget package to be digitally signed. Widget authors Authors and distributors can digitally sign widgets a widget as a mechanism to ensure continuity of authorship and distributorship. Prior to instantiation, a A user agent agent, or other validation system, can use the a digital signature to verify the data integrity of the files within a widget package and to confirm the signing key(s). This document specifies conformance requirements on both widget packages and user agents.

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

Publication as a Working Draft does not imply endorsement by This is the 30 March 2012 W3C Membership. Recommendation of the XML Digital Signatures for Widgets specification.  

This is a draft document has been reviewed by W3C Members, by software developers, and may be updated, replaced or obsoleted by other documents at any time. W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is inappropriate to cite this a stable document and may be used as other than work reference material or cited from another document. W3C's role in progress. This making the Recommendation is to draw attention to the 15 April 2010 Last Call Working Draft specification and to promote its widespread deployment. This enhances the functionality and interoperability of "Digital Signatures for Widgets". The Last Call period ends on 6 May 2010. the Web.

The title of public is encouraged to send comments to the document has been changed from "Widgets 1.0: Digital Signatures", WebApps Working Group's public mailing list  public-webapps@w3.org  ( archive ). See  W3C mailing list and archive usage guidelines .

This document is produced by the processing of same-document XML References has been changed to require use Web Applications WG , part of a Transform to specify Canonical XML 1.1 to minimize ambiguities, while recommending validators also support the case without a transform for backward compatibility. References have also been updated. Rich Web Client Activity in the W3C Interaction Domain . It is expected that this document will progress along the W3C's Recommendation track.

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 .

You can find the latest Editor's Draft of this document in the W3C's CVS repository , which is updated on a very regular basis. The public is encouraged to send comments to the WebApps Working Group's public mailing list public-webapps@w3.org ( archive ). See W3C mailing list and archive usage guidelines . A detailed list of changes from the previous version is also available from the W3C's CVS server. This document is produced by the Web Applications WG , part of the Rich Web Clients Activity in the W3C Interaction Domain .

Table of Contents

1. 1. 1 Introduction
   1. 1.1. 1.1 Versions, Namespaces Design goals and Identifiers 1.2. Definitions 1.3. Conventions 1.4. Example requirements
2. 2. 2 Design Goals and Requirements Conformance
3. 3. 3 Conformance Definitions
4. 4. 4 Locating Versions, namespaces, and Processing Digital Signatures for the Widget identifiers
5. 5. 5 Signature Syntax Algorithms, key lengths, and use in Widget Packages certificate formats
   1. 5.1. 5.1 Use of XML Signature in Widgets Note about X.509 data
6. 5.2. 6 Author Signature signature
   1. 5.2.1. 6.1 Naming Convention for an Author Signature convention
7. 5.3. 7 Distributor Signatures signatures
   1. 5.3.1. 7.1 Naming Convention for a Distributor Signature convention
8. 5.4. 8 X.509 Data Generating a digital signature
   1. 5.5. 8.1 Identifier Signature Property Example of a generated distributor signature
   6. Algorithms 6.1. Signature Algorithms
9. 6.2. 9 Digest Algorithms Validating digital signatures
10. 6.3. 10 Canonicalization Algorithms Locating signature files in a widget package
11. 7. Processing Rules 7.1. 11 Common Constraints for Signature Generation and Validation Security Considerations
12. 7.2. Signature Generation Acknowledgements
13. 7.3. Signature Verification Normative References
14. 8. Security Considerations Acknowledgements Informative References

1. 1 Introduction

This document defines a profile of the XML Signature Syntax and Processing 1.1 specification to allow a

A widget package to be digitally signed. Widget authors and distributors can be digitally sign widgets as a mechanism to ensure continuity of authorship and distributorship. Prior signed by an author to instantiation, produce a user agent can use the digital signature to verify the integrity file that cryptographically covers all of the files of a widget package that are not signature files (e.g., HTML files, CSS files, and JavaScript files). In this specification, this kind of signature is referred to confirm the signing key(s). This document specifies conformance requirements on both widget packages and user agents. as an author signature .

A widget package user agent or other entity can be signed by the use an author signature to determine:

• which entity alleges to have authored the widget,
• that the integrity of the widget producing an [XMLDSIG11] is as the author signature that cryptographically includes all intended,
• and whether a set of widgets came from the file entries other than signature files same author .

A widget package can also be signed by one or more distributors of the widget, producing [XMLDSIG11] signatures to produce a signature file that each cryptographically includes all of the non-signature file entries files as well as any author signature . 1.1. Versions, Namespaces and Identifiers 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 URI as the XML namespace for [XML] elements used by this specification: URI: http://www.w3.org/ns/widgets-digsig Implementations MUST support the [XML] specification and the [XML-Namespaces] specification. While use of the above namespace URI is REQUIRED for XML elements used by (if one was included). In this specification, the namespace prefix and entity declaration given below are merely editorial conventions used in this document. Their use by authors kind of digital signature documents is OPTIONAL . XML internal entity: <!ENTITY wsig "http://www.w3.org/ns/widgets-digsig"> Namespace Prefix: wsig: For resources referred to as a distributor signature . To be clear, distributor signatures countersign author signatures , but do not under the control countersign other distributor signatures . Because of this specification, we use the designated Uniform Resource Identifiers [URI] defined by the relevant specifications. For example: XML Signature [XMLDSIG-2ndEd] resources are defined in the ds: namespace http://www.w3.org/2000/09/xmldsig Additional XML Signature 1.1 [XMLDSIG11] resources are defined this, an author signature needs to be included in the ds11: namespace http://www.w3.org/2009/xmldsig11 Individual Signature Properties [XMLDSIG-Properties] a widget package such as Role are defined in the dsp: namespace http://www.w3.org/2009/xmldsig-properties Algorithms used by XML Security are defined in before a number of places, including XML Signature 1.1. See distributor signature or the XML Security Algorithm Cross-Reference for details [ XMLSecAlgs validation process ]. Note: No provision is made for an explicit version number defined in this specification. If a future version of this specification requires explicit versioning of the document format, a different namespace will be used. fail.

1.2. Definitions

A widget package is user agent or other entity can use a [Zip] distributor signature archive that conforms to the [Widgets Packaging] specification. determine:

A file entry is the data held by

• that a local file header , file data , and (optional) data descriptor , as defined in the [ZIP] specification, for each physical file contained in particular distributor has distributed a Zip archive. The root of the widget package is package,
• that the top-most path level integrity of the widget package that can logically contain one or more file entries, as defined in the [Widgets Packaging] specification. A file name is as the name of a file contained in a widget package (derived from the file name field of distributor intended,
• and whether a local file header set of a file entry ), as defined in widgets came from the [Widgets Packaging] specification. All file names MUST be treated as case-sensitive. In other words, case matters in file name comparisons. A digitally signed widget package is a widget package that contains one or more signature files same distributor . An unsigned widget package is a widget package that does not contain any signature files.

A signature file The complete signing model is a file entry containing a detached [XMLDSIG11] signature (as profiled illustrated in this specification) whose file name follows the naming conventions of a signature file name Figure 1 .

A signature file name is a file name for a file entry that represents a signature file .

2. 1.1 Design Goals and Requirements The design goals and requirements for this specification are addressed in the Widgets 1.0 Requirements document [Widgets Requirements] .

This document addresses the following requirements: requirements from the [Widgets Requirements] document:

• R48. Digital Signatures : this specification relies on [XMLDSIG11] [XMLDSIG] and [RFC5280] to address this requirement.

• R49. Multiple Signatures and Certificate Chains : this specification relies on [XMLDSIG11] [XMLDSIG] and [RFC5280] to address this requirement.

• R50. Signature Document Format : see signature file. file .

• R51. Support for Multiple Message Digest Algorithms : this specification supports SHA-256, SHA-256 , the reference element, and ds:SignedInfo element.

• R52. Support for Multiple Signature Algorithms : DSA-SHA-1, RSA-SHA-256, and ECDSA-SHA-256. this specification relies on the signature algorithms defined in [XMLDSIG] .

• R53. Key Lengths : minimum of 1024, but 2048 recommended. see the recommended key length .

• R54. Key Usage Extension : part of X.509v3.

• R55. Inclusion of Revocation Information : this specification relies on [XMLDSIG11] [XMLDSIG] and [RFC5280] to address this requirement.

In particular, this specification explicitly supports both author signatures and distributor signatures .

3. 2 Conformance

The key words MUST , MUST NOT , REQUIRED , SHOULD , SHOULD NOT , RECOMMENDED , MAY and OPTIONAL in this specification are to be interpreted as described in [RFC2119] .

As well as sections marked as non-normative, non-normative , the examples and notes, and security considerations in this specification are non-normative. Everything else in this specification is normative.

There are two classes of product that can claim conformance to this specification: specification, a signer and a validator :

• A signature file . A signer is a user agent . Products that generate implements [XMLDSIG] and digitally signs a widget signature MUST generate [XML] package documents in a manner that conform conforms to [XMLDSIG11] the requirements of this specification and conform in a manner that conforms to this specification. the applicable generation requirements of [Signature Properties] .

• A user agent validator is an implementation that attempts to support this specification. A a user agent MUST behave as described by that implements [XMLDSIG] and validates the signature files of a widget package in a manner that conforms to the requirements of this specification and in order a manner that conforms to claim conformance. the applicable validation requirements of [Signature Properties] .

  Implementers

Note: User agents that implement this specification are encouraged to provide mechanisms to enable allow end-users to install certificates for enabling digital certificates. This allows the verification of digital signatures within the widget package. package for when custom root certificates are not shipped with a runtime (e.g., for beta testing purposes).

4. 3 Locating and Processing Digital Signatures for the Widget Definitions

This section defines how to locate signature files in a widget package for processing. An implementation MUST achieve the same result as As the following algorithm terms are used to locate signature files throughout this specification, they are gathered here for the reader's convenience. The following list of terms is not exhaustive; other terms are defined throughout this specification.

A file is the uncompressed representation of a physical file contained in a widget package : Let (e.g., signatures config.xml be an empty list. ).

For each file entry in the root of the widget package , if the A file name matches is the naming convention for name of a distributor signature then append this file entry to the signatures list. An Implementation MUST perform contained in a case-sensitive comparison. widget package (excluding path information).

If The root of the signatures list widget package is not empty, sort the list top-most file-path level of signatures by the widget package , as defined in the [Widgets Packaging] specification.

A signature file name field is a detached [XMLDSIG] document, likely encoded in ascending numerical order (e.g. signature1.xml followed by signature2.xml followed by signature3.xml etc.). [UTF-8] .

Search the root of the A widget package is a [ZIP] for any file name archive that matches the naming convention for an author signature and then append this file entry conforms to the signatures list. An Implementation MUST perform a case-sensitive comparison. [Widgets Packaging] specification.

If A zip relative path is a string that conforms to the [ABNF] for signatures list is empty (meaning no signature files zip-rel-path were found), terminate this algorithm and treat this widget package as an unsigned widget package . Validate the signature files in the signature list specified in numerical descending order, with distributor signatures first (if any). [Widgets Packaging] .

4 Versions, namespaces, and identifiers

The decision This specification makes use of which (if any) distributor signatures [XML-Namespaces] , and uses [URI] are s to be validated identify resources, algorithms, and whether the author signature semantics.

The XML namespace for [XML] is validated is out of scope of this specification. This MAY be determined by the security policy elements used by the user agent. this specification is http://www.w3.org/ns/widgets-digsig

Numerical order The profile URI for this specification is the order based on the numeric portion of the signature file name. Thus in the case more than one distributor signature is to be processed, the highest numbered distributor signature is processed first. Ordering of widget signature files by the numeric portion of the file name can be used to allow consistent processing and possible optimization. http://www.w3.org/ns/widgets-digsig#profile

Every signature that No provision is verified MUST be verified according to Signature Verification defined made for an explicit version number in this specification. If a future version of this specification requires explicit versioning of the document format, a different namespace will be used.

5. 5 Signature Syntax Algorithms, key lengths, and use in Widget Packages certificate formats

5.1. Use of XML Signature in Widgets

A widget package MAY be digitally signed using the profile of [XMLDSIG11] defined by this specification. Note: A This specification relies on a user agent's security policy can affect how conformance to [XMLDSIG] for support of signature validation impacts operation, and may have additional constraints on establishing trust, including additional requirements on algorithms, certificate chain validation formats, canonicalization algorithms, and certificate revocation processing using CRLs [RFC5280] or OCSP [RFC2560] . Security policy may also require additional information to be conveyed in ds:KeyInfo . Security policy digest methods. As this specification is out a profile of scope [XMLDSIG] , it makes a number of this specification but has important implications for recommendations as to what signature file processing. When algorithms should be used when signing a widget package is signed according to this specification, the following requirements on a widget signature apply to any widget signature achieve optimum interoperability. See Signature Algorithms included in widget package : of [XMLDSIG] for the list of required algorithms.

Each The recommended signature file algorithm is RSA MUST appear at the root of using the widget package RSAwithSHA256 signature identifier: http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 .

Each widget signature The recommended key length for RSA MUST be a detached XML Signature that complies with is 4096 bits.

The recommended digest method is SHA-256 .

The recommended canonicalization algorithm is Canonical XML Signature Version 1.1 syntax [XMLDSIG11] (omits comments) as defined in [C14N11] . The identifier for the algorithm is http://www.w3.org/2006/12/xml-c14n11 .

Each widget signature MUST be generated and validated The recommended certificate format is X.509 version 3 as specified in a manner compliant with XML Signature 1.1 processing rules [XMLDSIG11] [RFC5280] .

5.1 Note about X.509 data

Each widget signature MUST contain a dsp:Profile signature properties element compliant with the [XMLDSIG-Properties] and this specification. This dsp:Profile property MUST section is informative. have the URI attribute value of http://www.w3.org/ns/widgets-digsig#profile .

Each widget A signature file MUST contain can have information contained in a dsp:Role ds:X509Data signature properties element compliant with element, as specified by the [XMLDSIG-Properties] [XMLDSIG] and this specification. Each widget signature MUST contain a dsp:Identifier signature properties element compliant with XML Signature Properties [XMLDSIG-Properties] This can include X.509 certificates, and/or CRL and/or OCSP response information that, if included, are conveyed according to the [XMLDSIG] and this specification. Every ds:Reference used within a widget signature MUST have X.509 v3 certificates provide means to express the basic constraints on a certificate. This allows URI CA attribute. certificates to be distinguished from end entity certificates, enabling more robust trust verification. See also [RFC5280] for more information.

6 Author signature

Every ds:Reference used within An author signature is a widget signature file MUST be one of the following two kinds of reference: Reference whose file name adheres to content within the same ds:Signature element Every ds:Reference to naming convention for an item within the widget author signature MUST use an IDREF value for the and whose [Signature Properties] ds:Reference Role element's URI attribute, referring to a unique ID (as defined in [XML-Schema-Datatypes] ) within the widget signature . Reference to a file entry in the same widget package The URI attribute of every ds:Reference value is equal to a file entry MUST be a URL-encoded [URI] zip relative path that identifies a file inside the widget package. 5.2. Author Signature The author role URI . An author signature can be used is intended to determine: be generated by the author of a the widget, that which is the integrity entity or entities whom claim authorship over the content of the widget is as the author intended, and whether two widgets came from the same author. package .

A widget package MAY can contain zero or one author signatures . In addition to the requirements on a widget signature , the following MUST be true of an author signature ‘ s [XMLDSIG-Properties] Role element ’s URI attribute value: .

Author Role Attribute value ( role URI ): :

http://www.w3.org/ns/widgets-digsig#role-author

Meaning: This widget signature represents the digital signature of the author of the widget package .

In addition, the ds:Signature MUST have ds:Reference s for every file entry of the widget package other than any widget signature .

5.2.1. 6.1 Naming Convention for an Author Signature convention

The author-sig-filename [ABNF] rule defines the naming convention for an author signature , as it applies to the signature file name of the author signature :

author-sig-filename

=
%x61.75.74.68.6f.72.2d.73.69.67.6e.61.74.75.72.65.2e.78.6d.6c

The author-sig-filename rule defines the lower-case (case-sensitive) string " author-signature.xml ".

7 Distributor signatures

A distributor signature is a signature file matching whose file name adheres to the naming convention for a distributor signature and whose [Signature Properties] Role element's author-sig-filename URI [ABNF] rule MUST contain a dsp:Role signature property having attribute value is equal to the URI for an Author distributor role as defined in this specification or the signature MUST be flagged as being in error. 5.3. Distributor Signatures The URI . A distributor signature can be used is intended to determine: that be generated by a particular distributor has distributed this widget resource, and , which is a third party that is distributing the integrity of the widget package is as on behalf of the distributor intended. author.

A widget package MAY can contain zero, one, or more distributor signatures .

In addition to the requirements on a widget signature , the following MUST be true of an distributor signature ‘ s [XMLDSIG-Properties] Role element ’s URI attribute value:

Distributor Role Attribute value ( role URI ): :

http://www.w3.org/ns/widgets-digsig#role-distributor Meaning: This widget signature represents the digital signature of a distributor of the widget package .

In addition, the ds:Signature MUST include ds:Reference s for every file entry of the widget package , including any author signature , but excluding any distributor signatures . In other words, distributor signature s MUST countersign author signatures , but MUST NOT countersign other distributor signatures .

5.3.1. 7.1 Naming Convention for a Distributor Signature convention

Each distributor signature MUST have has a file name consisting of the lower-case string " signature " followed by a digit in the range 1-9 inclusive, followed by an optional zero or more digits in the range 0-9 inclusive and then the lower-case string " .xml ".

The dist-sig-filename [ABNF] rule formally defines the naming convention for a distributor signature , as it applies to the signature file name of a distributor signature :

dist-sig-filename = signature-string non-zero-digit 
                    *DIGIT  xml-suffix-string
signature-string  = %x73.69.67.6e.61.74.75.72.65
non-zero-digit    = %x31-39

non-zero-digit    = %x31-39                       

xml-suffix-string
=
%x2e.78.6d.6c

• The signature-string rule defines the lower-case (case-sensitive) string " signature ".

• The non-zero-digit rule defines a digit in the range 1-9 . , thus leading zeros are disallowed by this rule.

• DIGIT is defined in [ABNF] as a digit in the range 0-9 .

• The xml-suffix-string rule defines the lower-case (case-sensitive) string " .xml ".

An example is "signature20.xml". signature20.xml .

Leading zeros are disallowed in

8 Generating a digital signature

To digitally sign the numbers. A file entry whose file name contents of a widget package does not match the above ABNF MUST be ignored, meaning that with an implementation author signature or with a distributor signature , a signer MUST NOT treat run the file entry as algorithm to generate a digital signature file .

For example, a file with

The algorithm below relies on the file name signature generation rules " signature01.xml " will be ignored. It of [XMLDSIG] (Section 3.1) and the various generation rules defined in [Signature Properties] (links to the appropriate sections of those specifications are provided where needed for generation). When performing the algorithm below, it is OPTIONAL RECOMMENDED that a signer use the recommended canonicalization algorithm , the recommended signature file name s of distributor signatures algorithm , the recommended key length form a contiguous set of numeric values. for the appropriate algorithm, and the recommended certificate format .

Within The algorithm to generate a widget package these digital signature files MUST be ordered based on is as follows:

1. Using the numeric portion Processing Rules of [XMLDSIG] , perform reference generation for each file of the widget package that is not a signature file name. Thus, for example, signature2.xml precedes signature11.xml . A file matching . Set the a dist-sig-filename URI [ABNF] rule MUST contain a attribute of each dsp:Role ds:Reference signature property having to be the URI for a Distributor role as defined in this specification or zip relative path that identifies the signature MUST be flagged as being in error. file inside the widget package .

   5.4. X.509 Data

2. Every widget signature MAY have additional information contained in the signature Optionally, include a ds:X509Data ds:KeyInfo element as specified by in the [XMLDSIG11] manner described in [XMLDSIG] specification. This MAY (see The KeyInfo Element for how to do this). The element can include X.509 certificates, and/or CRL and/or OCSP response information that, if included, MUST be conveyed according to the [XMLDSIG11] [RFC5280] specification. The (see note about X.509 certificate format MUST be supported when certificates are used data in this specification).

3. Generate the ds:X509Data . This is container elements for [Signature Properties] in accordance with the mandatory certificate format . The RECOMMENDED version Signature Properties Placement section of the certificate format is X.509 version 3 as specified in [RFC5280] [Signature Properties] . Implementations MUST

4. If generating an author signature , generate a role property and let its URI attribute value be prepared to accept X.509 v3 certificates [RFC5280] the author role URI .

   Note: v3 certificates are necessary to use the v3 extension to express the basic constraints on

5. Otherwise, if generating a certificate. This allows CA certificates to be distinguished from end entity certificates, enabling more robust trust verification. distributor signature :

   5.5.

   1. Generate a role property in the manner specified in [Signature Properties] and let its Identifier URI Signature Property attribute value be the distributor role URI .

   2. The signer uses If the dsp:Identifier widget package contains an author signature property to uniquely identify , perform reference generation on the author signature to enable signature management. It MUST be unique for a given signer. Signing parties are expected to ensure that and set the resulting dsp:Identifier ds:Reference signature property value is unique for the widget packages that they sign. element's 6. Algorithms URI attribute to be author-signature.xml .

6. Definitions of Generate an identifier property in the algorithm URI identifiers manner specified in [XMLDSIG11] [Signature Properties] .

7. Generate a profile property take precedence if there is any difference in this document. Rules the manner specified in [XMLDSIG11] [Signature Properties] regarding use of these algorithms MUST be followed. Note that use of optional algorithms may result in signatures that are not interoperable with implementations that do not support these algorithms. Authors are cautioned to take this into consideration. 6.1. Signature Algorithms The following signature algorithms MUST be supported: RSAwithSHA256: whose http://www.w3.org/2001/04/xmldsig-more#rsa-sha256 DSAwithSHA1: URI http://www.w3.org/2000/09/xmldsig#dsa-sha1 REQUIRED for signature verification, OPTIONAL for generation attribute is the profile URI .

8. The Optionally, include any additional [Signature Properties] (e.g., created , expires , replayProtect ) by following signature algorithms SHOULD be supported: the appropriate generation rules specified in [Signature Properties] .

   ECDSAwithSHA256:

9. Generate a reference to the http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256 ds:Object This is ECDSA over that contains the P-256 prime curve specified signature properties created in Section D.2.3 of FIPS 186-3 [FIPS186-3] the steps above.

10. Perform signature generation (and as defined in [XMLDSIG] .

11. Serialize the signature as a [UTF-8] encoded [XML] document using the SHA-256 hash algorithm). appropriate naming convention depending on its role: using either the naming convention for a distributor signature or the naming convention for an author signature .

    Note: Although all implementations may not support this optional algorithm, implementation It is encouraged since it may become mandatory in not a subsequent release requirement that the file names of this specification. This may also be necessary if any security issues distributor signatures are discovered with the currently required algorithm. serially numbered signatures1.xml , signature2.xml , signature3.xml , and so on. A user agent MAY support additional signature algorithms. The RECOMMENDED key length ( recommended key length ) of signer can to use whatever pattern they want, so long as the key used file name conforms to generate the naming convention for a distributor signature is 2048 bits. . The key length numeric part of the key used to generate file name affects the order in which signature MUST NOT be less than 1024 bits. The signer MUST NOT generate files are processed by a validator (see the algorithm to locate signature files in a widget package ). So, to ensure that a distributor signature is processed before any other distributor signatures using key lengths of less , assign a number greater than 2048 bits unless that of all the life time other distributor signatures for the numeric part of the signature is less than one year. distributor signature's file name.

12. Place the generated signature file at the root of the widget package .

6.2. 8.1 Digest Algorithms Example of a generated distributor signature

The following digest algorithms MUST be supported: REQUIRED : SHA-256 http://www.w3.org/2001/04/xmlenc#sha256 A user agent MAY This section is non-normative. support additional digest methods. 6.3. Canonicalization Algorithms

The following canonicalization algorithms MUST be supported: REQUIRED : Exclusive XML Canonicalization 1.0 (omits comments) [XML-exc-C14N] is an example of a distributor signature document, named http://www.w3.org/2001/10/xml-exc-c14n# A user agent MAY support additional XML canonicalization methods. signature1.xml . For legibility, the example omits the content of the various cryptographic digests and instead uses "…":

<?xml version="1.0" encoding="UTF-8"?>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#" 
  Id="DistributorSignature">
 <SignedInfo>
  <CanonicalizationMethod 
   Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>
  <SignatureMethod
   Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
  <Reference URI="config.xml">
   <DigestMethod
    Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
   <DigestValue>…</DigestValue>
  </Reference>
  <Reference URI="index.html">
    <DigestMethod
     Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
     <DigestValue>…</DigestValue>
  </Reference>
  <Reference URI="#prop">
   <Transforms>
    <Transform Algorithm="http://www.w3.org/2006/12/xml-c14n11"/>
   </Transforms>
   <DigestMethod 
    Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
   <DigestValue>…</DigestValue>
  </Reference>
 </SignedInfo>
 <SignatureValue>…</SignatureValue>
 <KeyInfo>
  <X509Data>
   <X509Certificate>…</X509Certificate>
  </X509Data>
 </KeyInfo>
 <Object Id="prop"> 
  <SignatureProperties
   xmlns:dsp="http://www.w3.org/2009/xmldsig-properties">
   <SignatureProperty Id="profile" Target="#DistributorSignature">
    <dsp:Profile URI="http://www.w3.org/ns/widgets-digsig#profile"/>
   </SignatureProperty> 
   <SignatureProperty Id="role" Target="#DistributorSignature">
    <dsp:Role
      URI="http://www.w3.org/ns/widgets-digsig#role-distributor"/>
   </SignatureProperty> 
   <SignatureProperty Id="identifier" Target="#DistributorSignature">
    <dsp:Identifier>…</dsp:Identifier>
   </SignatureProperty> 
  </SignatureProperties> 
 </Object>  
</Signature>

7. 9 Processing Rules Validating digital signatures

7.1. Common Constraints for Signature Generation and Validation The following constraints apply to both Signature Generation

To validate the signature files and Signature Verification . These constraints MUST be observed when generating of a widget signature package , a validator and MUST be verified as met when validating a widget signature run the algorithm to validate digital signatures .

A widget signature The algorithm below relies on the Core Validation MUST have a ds:Reference for every file entry of [XMLDSIG] that is not a widget signature . A distributor signature and the various validation rules defined in [Signature Properties] MUST have a ds:Reference (links to the appropriate sections of those specifications are provided where needed for any author signature , if one validation). This specification does not define the means or format of a failure notification: handling of signatures that are in error is present within left up to the widget package . For each ds:Reference element: implementation. The URI attribute MUST reason for validation failure can be a zip relative path from returned by the root implementation to an external entity, including reasons related to Reference validation, Signature validation, Signature Property validation and/or certificate and CRL/OCSP verification. The decision of the widget package which (if any) distributor signatures are to be validated and whether the file entry author signature being referenced. The Algorithm attribute is validated is out of the ds:digestMethod scope of this specification. This MUST MAY be one of determined by the digest algorithms security policy used by the validator .

A ds:Reference to same-document XML content MUST have During validation , a ds:Transform element child that specifies the canonicalization method. Canonical XML 1.1 user agent MUST MAY be specified treat a widget package as being in error if it deems that the Canonicalization Algorithm key length for this transform. A ds:Reference that a signature algorithm to is not large enough to same-document XML content MUST NOT have any ds:Transform elements. be secure (e.g., under 2048 bits for  RSA  and  DSA ).

An implementation SHOULD be able to process a ds:Reference to same- document XML content when that ds:Reference does not have a ds:Transform child element, for backward compatibility. In this case the default canonicalization The algorithm Canonical XML 1.0 will be used, to validate digital signatures is as specified in XML Signature 1.1. follows:

Note: The relevant section in XML Signature 1.1 is section 4.4.3.2, "The Reference Processing Model". This section states "Unless the URI- Reference is such a ‘ same-document ’ reference ,

1. Let signatures list be the result of dereferencing the URI-Reference MUST be an octet stream. In particular, an XML document identified by URI is not parsed by applying the algorithm to locate signature application unless the URI is a same-document reference or unless files in a transform that requires XML parsing is applied." In widget package .

2. If the same section signatures list is empty (meaning no signature files were found in the specification notes, "In widget package), terminate this specification, a ‘ same- document ’ reference is defined algorithm and treat the widget package as a URI-Reference that consists of a hash sign (‘ # ’) followed by a fragment or alternatively consists of an empty URI..." [XMLDSIG11] . unsigned widget package: It is left up to the user agent to decide how to treat unsigned widget packages.

3. Every Signature Property required by this specification MUST be incorporated into the For each signature as follows: in signatures list :

   1. A widget If signature is not a valid [XMLDSIG] MUST include document, then signature is in error .

   2. Check that signature has a ds:Object element within the ds:Signature element. This ds:Object element MUST have an Id ds:Reference attribute for every file that is referenced by not a ds:Reference element within the signature ds:SignedInfo element. file . If any non-signature file is not listed, then signature is in error .

   3. This ds:Object element MUST contain Check that signature has a single same-document ds:SignatureProperties ds:Reference element that MUST contain to a different ds:SignatureProperty ds:Object element container for each property required by this specification. Each ds:Signature property required by this specification MUST meet [Signature Properties] in accordance with the syntax requirements Signature Properties Placement section of [XMLDSIG-Properties] [Signature Properties] .

   4. The ds:Signature MUST meet the following requirements: Optionally, if the ds:Signature's key length for a given signature algorithm (e.g.,  RSA ) is less than a user agent predefined minimum key length, then  signature  is  in error .

   5. The Algorithm attribute of Validate the ds:CanonicalizationMethod element MUST be one of profile property against the canonicalization algorithms profile URI in the manner specified in [Signature Properties] . If the profile property is missing or invalid, then signature is in error .

   6. The ds:SignatureMethod algorithm used in Validate the ds:SignatureValue element MUST be one of identifier property in the signature algorithms manner specified in [Signature Properties] . The ds:Signature MUST be produced using a key of If the recommended key length identifier property is missing or stronger (meaning larger than 2048 bits). or invalid, then signature is in error .

   7. The ds:KeyInfo element MAY be included and MAY include certificate, CRL and/or OCSP information. If so, it MUST be compliant with signature 's file name matches the [XMLDSIG11] naming convention for an author signature , validate the role property specification. If certificates are used, they MUST conform to against the mandatory certificate format author role URI . The ds:SignedInfo element MUST include all If the ds:Reference elements listed role property is missing or or invalid, then signature is in items 1, 2 and 4 of this section. error .

   8. The widget Otherwise, if signature 's file name MUST be serialized as a [UTF-8] encoded [XML] document and be named using the appropriate naming convention: either matches the naming convention for a distributor signature :

      1. Validate the role property against the distributor role URI . If the role property is missing or or invalid, then signature is in error .

      2. If an author signature is present in the naming convention widget package, verify that signature has a ds:Reference for an the author signature .

      7.2. Signature Generation

   9. A widget signature Optionally, validate any other [Signature Properties] MUST be generated according to supported by the Core Generation rules user agent in the manner specified in [XMLDSIG11] , including rules on Reference Generation and Signature Generation. [Signature Properties] .

   10. Every ds:Reference to same-document XML content MUST have exactly one ds:Transform element to specify the canonicalization method. Canonical XML 1.1 MUST be specified as the Canonicalization Algorithm. Perform reference validation and signature validation on signature . If validation fails, then signature is in error .

       Note: that

4. If all signatures validate successfully, treat this specifically means that as a ds:Reference signed widget package. It is left up to the ds:Object element will require a ds:Transform element user agent to specify canonicalization method. A reference decide how to config.xml will not, however, since it is not a same-document reference. treat singed widget packages.

   The Common Constraints for Signature Generation and Validation MUST be met on

10 Locating signature generation. files in a widget package

A unique identifier string for the The algorithm to locate signature MUST be placed files in a widget package is as follows. This algorithm makes use of the dsp:Identifier signature property by concept of numerical order , which is the signer. This MUST be order based on the numeric portion of a unique signing string for all widget signatures distributor signature's created by file name . Thus in the signer. Signing parties are expected case more than one distributor signature is to ensure that be processed, the dsp:Identifier highest numbered distributor signature property value is unique for the widgets that they sign. ordered first.

7.3. Signature Verification

1. A widget signature MUST Let signatures be validated according to Core Validation, as defined in XML Signature [XMLDSIG11] , including Reference Validation and Signature Validation. an empty list.

2. The Common Constraints for Signature Generation and Validation For each file MUST be met on at the root of the widget package , if the file name case-sensitively matches the naming convention for a distributor signature validation. then append this file to the signatures list.

3. If a ds:KeyInfo element the signatures list is present, then it MUST conform to not empty, sort the [XMLDSIG11] specification. If present, list of signatures by the user agent MUST perform Basic Path Validation [RFC5280] file name on the signing key and SHOULD perform revocation checking as appropriate. in ascending numerical order .

   When validating a Widget Signature, a validator MUST be able to process a

   For example, ds:Reference signature1.xml that has a followed by ds:Transform signature2.xml specifying the canonicalization method. The validator MUST be able to process a followed by ds:Reference signature3.xml that specifies Canonical XML 1.1 as a canonicalization method. A validator SHOULD be able to process a and so on. As another example, ds:Reference signature9.xml to same- document XML content when that followed by ds:Reference signature44.xml does not have followed by ds:Transform , for backward compatibility. signature122134.xml and so on.

4. If widget signature validation is successful any external entities (e.g., a user agent that implements [Widgets Packaging] relying on the validation of Search the widget signature MUST be notified root of the success. If widget signature package validation fails for any reason, any external entities (e.g., a user agent that implements [Widgets Packaging] file name ) relying on the validation of the widget signature MUST be notified of the failure. This specification does not define that case-sensitively matches the means or format of a failure notification, which is left up to implementers. The reason naming convention for validation failure MAY be returned by the implementation to an external entity, including reasons related to Reference validation, Signature validation, Signature Property validation and/or certificate author signature and CRL/OCSP verification. then append this file to the signatures list.

5. Return signatures .

8. 11 Security Considerations

This section is non-normative.

In addition to the security considerations described in this section, the Security Considerations of [XMLDSIG] apply to this specification. In addition, the security considerations of [Widget Packaging] also apply to this specification.

The signature scheme described in this document deals with the content present inside a potentially compressed widget package. package . This implies that, in order to verify a widget signature, implementations need signature file , a user agent needs to decompress a data stream that can come from an arbitrary source. A signature according to this specification does not limit the attack surface of decompression and unpacking code used during signature extraction and verification.

Care should needs to be taken to avoid resource exhaustion attacks through maliciously crafted widget packages during signature verification. Implementations should be careful about trusting path components found in the widget package. Such path components might be interpreted by operating systems as pointing at security critical files outside the widget environment proper, and naive unpacking of widget packages into the file system might lead to undesirable and security relevant effects, such as overwriting of startup or system files. validation.

There Because there is no single signature file that includes all files of a widget package, including all of the signature files. This files, this leaves a widget package subject to an attack where distributor signatures can be removed or added. An author signature could also be attacked by removing it the signature and any distributor signatures , if they are present. A signature file may can also be renamed, which can affect the order in which distributor signatures are processed.

Mechanisms to install new root certificates in a If the user agent should be subject to security critical mechanisms. End-users supports installing a new root certificate, an end-user should be made aware of what they are doing doing, and why when installing a new root certificate. why.

A user agent's security policy can affect how signature validation impacts operation, and can have additional constraints on establishing trust, including additional requirements on certificate chain validation and certificate revocation processing using CRLs [RFC5280] or OCSP [RFC2560] . Security policy can also require additional information to be conveyed in ds:KeyInfo . Security policy is out of scope of this specification but has important implications for signature file processing.

Acknowledgements

The Web Applications working group would like to thank members of the W3C XML Security working group Working Group for their comments and suggestions, as well as all reviewers of earlier drafts of this document.

Normative References

[ABNF]

RFC 5234, RFC 5234. Augmented BNF for Syntax Specifications: ABNF , D. Crocker and P. Overell. January 2008. http://www.ietf.org/rfc/rfc5234.txt IETF.

[C14N11]

Canonical XML Version 1.1 , J. Boyer, M. Marcy. 2 May 2008, W3C Recommendation. http://www.w3.org/TR/2008/REC-xml-c14n11-20080502/ [FIPS186-3] FIPS PUB 186-3 . Digital Signature Standard (DSS). U.S. Department of Commerce/National Institute of Standards and Technology. June 2009. http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf W3C.

[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels , S. Bradner. IETF, March 1997. http://www.ietf.org/rfc/rfc2119 [RFC2560] X.509 Public Key Infrastructure Online Certificate Status Protocol - OCSP , M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams; June 1999. http://www.ietf.org/rfc/rfc2560.txt IETF.

[RFC5280]

Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile , D. Cooper, S. Santesson, S. Farrell, S. Boeyen, R. Housley, W. Polk, May 2008. http://www.ietf.org/rfc/rfc5280.txt IETF.

[UTF-8]

RFC 2279 , UTF-8, a transformation format of ISO 10646 . F. Yergeau. January 1998. http://www.ietf.org/rfc/rfc2279.txt , IETF.

[URI]

RFC 3986. Uniform Resource Identifiers (URI): Generic Syntax , T. Berners-Lee, R. Fielding, L. Masinter. January 2005. http://www.ietf.org/rfc/rfc3986.txt IETF.

[Widgets Packaging]

Widget Packaging and Configuration , M. Cáceres. W3C Candidate Recommendation. http://www.w3.org/TR/widgets/ [Widgets Requirements] Widgets 1.0 Requirements , M. Cáceres. W3C Working Draft, 30 April 2009. http://www.w3.org/TR/2009/WD-widgets-reqs-20090430/ W3C.

[XML]

Extensible Markup Language (XML) 1.0 (Fifth Edition) , T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, F. Yergeau. W3C Recommendation 26 November 2008. [XML-exc-C14N] Exclusive XML Canonicalization Version 1.0 , J. Boyer, D. Eastlake 3rd., J. Reagle. W3C Recommendation. 18 July 2002. http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/ W3C.

[XML-Namespaces]

Namespaces in XML 1.0 (Second Edition) , T. Bray, D. Hollander, A. Layman, R. Tobin. W3C Recommendation, 16 August 2006. http://www.w3.org/TR/2006/REC-xml-names-20060816/ W3C.

[XMLDSIG11] [XMLDSIG]

XML Signature Syntax and Processing, Version 1.1 Processing , D. Eastlake et al. W3C Working Draft 04 February 2010. http://www.w3.org/TR/2010/WD-xmldsig-core1-20100204/ W3C.

[XMLDSIG-2ndEd] [Signature Properties]

XML Signature Syntax and Processing (Second Edition) Properties , D. Eastlake et al. W3C Recommendation, 10 June 2008. http://www.w3.org/TR/2008/REC-xmldsig-core-20080610/ (Work in progress), W3C.

[XMLSecAlgs] [ZIP]

XML Security Algorithm Cross-Reference , F. Hirsch, T. Roessler, K. Yiu, W3C Working Draft 16 March 2010. http://www.w3.org/TR/2010/WD-xmlsec-algorithms-20100316/ [XMLDSIG-Properties] XML Signature Properties .ZIP File Format Specification , F. Hirsch, W3C Working Draft 04 February 2010. http://www.w3.org/TR/2010/WD-xmldsig-properties-20100204/ PKWare Inc.

Informative References

[XML-Schema-Datatypes] [RFC2560]

XML Schema Part 2: Datatypes W3C Recommendation X.509 Public Key Infrastructure Online Certificate Status Protocol - OCSP , P. Biron, A. Malhotra. May 2001. http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/ IETF.

[ZIP] [Widgets Requirements]

.ZIP File Format Specification Widgets Requirements . PKWare Inc. September 28, 2007. Version 6.3.2. , W3C.