Digital Signatures for Widgets

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 and distributors can digitally sign widgets as a mechanism to ensure continuity of authorship and distributorship. Prior to instantiation, a user agent can use the digital signature to verify the integrity of the 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 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 is the 11 May 2010 Last Call Working Draft of "Digital Signatures for Widgets". The Last Call period ends on 1 June 2010.

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.

Changes Since Last Publication

Since the last publication, the Working Group made further changes to the specification. The Working Group believes that these changes should have limited impact on existing implementation and the changes were mostly to clarify certain ambiguous aspects detailed below. Regardless, if you have implemented a previous draft, then you should read this section carefully as it could potentially affect your implementation.

The following normative statements were removed from the specification:

1. The URI attribute of every ds:Reference to a file entry must be a URL-encoded [URI] zip relative path that identifies a file inside the widget package.

2. Within a widget package these signature files must be ordered based on the numeric portion of the signature file name.

For 1., Zip-relative paths are URI safe so URL Encoding is not necessary. Also, the algorithm for looking up files would fail because the algorithm did not instruct user agents to decode encoded URIs. In this new version of the spec, a signer is no longer required to encode Zip-relative paths.

For 2., It is the WG's position that this assertion was putting an unnecessary optimization on the signer (and might be beyond the control of the signer, as might be the case when the author manually has to create the zip file). It was evident that 2. was simply an optimization because the validator uses the "Locating and Processing Digital Signatures for the Widget". Using that rule assumes that the signatures will be in a random order within the zip archive. Removing 2. from the specification should have no impact on current implementations.

Lastly, members of the Mobile Web Test Suites Working Group pointed out that, aside from a number of editorial issues, the conformance model of the previous draft was ambiguous: it mixed conformance criteria for too many products. Because of the ambiguous conformance model, it became clear that it would not be possible to create a suitable test suite. To overcome this limitation in the specification, the Working Group applied the Method for Writing Testable Conformance Requirements defined in [Test-Methodology]. The result is a restructured specification whose conformance model now only applies to two classes of products: signers and validators. The Working Group believes that the specification is testable, and a test suite harness has been created that will allow testing those two products independently.

Table of Contents

• 1. Introduction
  • 1.1. Conventions Used in This Document
  • 1.2. Definitions
  • 1.3. Versions, Namespaces and Identifiers
  • 1.4. Example
• 2. Design Goals and Requirements
• 3. Conformance
• 4. Signer, Validator, Implementation
• 5. Signature Generation
• 6. Signature Validation
• 7. Signature Syntax and use in Widget Packages
  • 7.1. Requirements on Widget Signatures
  • 7.2. Author Signature
    • 7.2.1. Naming Convention for an Author Signature
  • 7.3. Distributor Signatures
    • 7.3.1. Naming Convention for a Distributor Signature
  • 7.4. X.509 Data
  • 7.5. Identifier Signature Property
• 8. Algorithms
  • 8.1. Signature Algorithms
  • 8.2. Digest Algorithms
  • 8.3. Canonicalization Algorithms
• 9. Processing Rules
  • 9.1. Locating and Processing Digital Signatures in a Widget Package
  • 9.2. Common Constraints for Signature Generation and Validation
• 10. Security Considerations
• Acknowledgements
• Normative References
• Informative References

1. Introduction

A widget package can be signed by the author producing an [XMLDSIG11] signature that cryptographically includes all of the file entries other than signature files. A widget package can also be signed by one or more distributors of the widget, producing [XMLDSIG11] signatures that each cryptographically includes all of the non-signature file entries as well as any author signature.

1.1. Conventions Used in This Document

This section is non-normative.

Defined terms appear as this sample defined term. Such terms are referenced as sample defined term, providing a link back to where the term is defined.

Words that denote a conformance clause or testable assertion use keywords from [RFC2119]: MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, RECOMMENDED, MAY and OPTIONAL.

Variables are formatted specially, e.g. variable. Code is also specially formatted, such as code.

Examples are highlighted to indicate the whole:

<?xml version="1.0" encoding="UTF-8"?>

Notes are highlighted specially and are used to note editorial issues, or items to be aware of.

This specification uses [ABNF] syntax to define file names. Rules are concatenated by being written next to each other. A rule prefixed by * means zero or more. See [ABNF] for details on this syntax.

1.2. Definitions

The following terms are used throughout this specification so they are gathered here for the readers convenience. The following list of terms is not exhaustive; other terms are defined throughout this specification.

A widget package is a [ZIP] archive that conforms to the [Widgets Packaging] specification.

A file entry is the data held by a local file header, file data, and (optional) data descriptor, as defined in the [ZIP] specification, for each physical file contained in a Zip archive.

The root of the widget package is the top-most path level of the widget package that can contain one or more file entries, as defined in the [Widgets Packaging] specification.

A file name is the name of a file contained in a widget package (derived from the file name field of a local file header of a file entry), as defined in the [Widgets Packaging] specification.

A digitally-signed widget package is a widget package that contains one or more signature files.

An unsigned widget package is a widget package that does not contain any signature files.

A signature file is a file entry containing a detached [XMLDSIG11] signature that adheres to the common constraints for signature generation and validation whose file name conforms to the naming conventions of a signature file name. Signature files are located at the root of the widget package.

A signature file name is a file name for a file entry that represents a signature file. This specification defines the naming conventions for both author signatures and distributor signatures.

A widget signature is an [XMLDSIG11] signature, as contained in a signature file. See also author signature and distributor signature.

A zip relative path is a string that conform to the [ABNF] for zip-rel-path as specified in [Widgets Packaging].

1.3. Versions, Namespaces and Identifiers

This specification makes use of [XML-Namespaces], and uses Uniform Resource Identifiers [URI] to identify resources, algorithms, and semantics.

The following URI is the XML namespace for [XML] elements used by this specification:

Widget DigSig URI:

http://www.w3.org/ns/widgets-digsig

Note: While use of the above namespace URI is mandatory for XML elements used by this specification, the namespace prefix and entity declaration given below are merely editorial conventions used in this document. Their use by authors of digital signature documents is optional.

XML internal entity:

<!ENTITY wsig "http://www.w3.org/ns/widgets-digsig">

Namespace Prefix:

wsig:

Note: No provision is 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.

1.4. Example

This section is non-normative.

<?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="icon.png">
   <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="#DistributorASignature">
    <dsp:Profile URI="http://www.w3.org/ns/widgets-digsig#profile"/>
   </SignatureProperty> 
   <SignatureProperty Id="role" Target="#DistributorASignature">
    <dsp:Role
      URI="http://www.w3.org/ns/widgets-digsig#role-distributor"/>
   </SignatureProperty> 
   <SignatureProperty Id="identifier" Target="#DistributorASignature">
    <dsp:Identifier>07425f59c544b9cebff04ab367e8854a</dsp:Identifier>
   </SignatureProperty> 
  </SignatureProperties> 
 </Object>  
</Signature>

2. Design Goals and Requirements

The design goals and requirements for this specification are addressed in the [Widgets Requirements] document. This document addresses the following requirements:

• R48. Digital Signatures: this specification relies on [XMLDSIG11] and [RFC5280] to address this requirement.
• R49. Multiple Signatures and Certificate Chains: this specification relies on [XMLDSIG11] and [RFC5280] to address this requirement.
• R50. Signature Document Format: see signature file.
• R51. Support for Multiple Message Digest Algorithms: this specification supports 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.
• R53. Key Lengths: minimum of 1024, but 2048 recommended.
• R54. Key Usage Extension: part of X.509v3.
• R55. Inclusion of Revocation Information: this specification relies on [XMLDSIG11] and [RFC5280] to address this requirement.

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

3. 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]. When intended as conformance requirements, the words appear capitalized.

As well as sections marked as 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:

• A signer.
• A validator.

4. Signer, Validator, Implementation

A signer is an implementation of this specification that follows the rules for signature generation to digitally sign the contents of a widget package.

A validator is an implementation of this specification that follow the rules for signature validation to validate the digital signatures within a widget package.

When a conformance requirement applies to both a signer and a validator, the generic term implementation is used in this specification.

Note: User agents that implement this specification are encouraged to provide mechanisms to enable end-users to install certificates for enabling verification of digital signatures within the widget package.

5. Signature Generation

This section defines the conformance requirements for signature generation as they apply to a signer.

A signer MUST generate a widget signature according to the Core Generation rules specified in [XMLDSIG11], including rules on Reference Generation and Signature Generation.

A signer MUST place any generated signature file at the root of the widget package.

A signer MUST apply the Common Constraints for Signature Generation and Validation upon signature generation.

The signer MUST NOT generate widget signatures using key lengths of less than the recommended key length unless the life time of the signature is less than one year. Regardless, the key length of the key used by a signer to generate the signature MUST NOT be less than 1024 bits.

If generating an author signature, the signer MUST include a dsp:Role signature property having the URI value for an author role.

If generating an distributor signature, the signer MUST include a dsp:Role signature property having the URI value for an distributor role.

It is OPTIONAL for a signer to make the signature file names of distributor signatures form a contiguous set of numeric values (i.e., it is not required that signature files names of distributor signatures follow the pattern signatures1.xml, signature2.xml, signature3.xml, and so on. Signers are free to use whatever pattern they want, so long as the file name conforms to the naming convention for a distributor signature).

A signer MUST ensure that every ds:Reference to same-document XML content has exactly one ds:Transform element to specify the canonicalization method.

Note: This means that a ds:Reference to the ds:Object element will require a ds:Transform element to specify canonicalization method. A reference to config.xml will not, however, since it is not a same-document reference.

A signer MUST place a unique identifier string for the signature in the dsp:Identifier signature property. This MUST be a unique signing string for all widget signatures created by the signer.

Note: Signing parties are expected to ensure that the dsp:Identifier signature property value is unique for the widgets that they sign.

6. Signature Validation

This section defines the conformance requirements for signature validation as they apply to a validator.

If widget signature validation is successful or fails, the validator MUST notify any external entities relying on the validation of the widget signature. An example of an external entity is, for example, a user agent that implements [Widgets Packaging].

Note: This specification does not define the means or format of a failure notification, which is left up to implementers. The reason for validation failure can be returned by the implementation to an external entity, including reasons related to Reference validation, Signature validation, Signature Property validation and/or certificate and CRL/OCSP verification.

To locate the signatures within a widget package, a validator MUST use the rule to locate signature files in a widget package.

A validator MUST ignore any file entry whose file name does not conform to the naming convention for a distributor signature or to the naming convention for an author signature.

For example, a validator will ignore a file with the file name "signature01.xml".

A validator MUST validate a widget signature according to Core Validation including Reference Validation and Signature Validation, all of which are defined in [XMLDSIG11].

A validator MUST verify the Common Constraints for Signature Generation and Validation upon signature validation.

If a validator finds that a file entry matching the naming convention for a distributor signature that does not contain a dsp:Role signature property having the URI for a distributor role, then the validator MUST treat the signature as being in error.

If a validator finds that a file entry matching the naming convention for an author signature that does not contain a dsp:Role signature property having the URI for a author role, then the validator MUST treat the signature as being in error.

If a ds:KeyInfo element is present, then a validator MUST check that the ds:KeyInfo conforms to the [XMLDSIG11] specification by performing Basic Path Validation [RFC5280] on the signing key. A validator SHOULD perform revocation checking as appropriate.

When validating a widget signature, a validator MUST be able to process a ds:Reference that has a ds:Transform specifying the canonicalization method.

A validator MUST support [C14N11] to process a ds:Reference that specifies [C14N11] as a canonicalization method.

A validator SHOULD be able to process a ds:Reference to same- document XML content when that ds:Reference does not have ds:Transform, for backward compatibility.

7. Signature Syntax and use in Widget Packages

7.1. Requirements on Widget Signatures

Note: A user agent's security policy can affect how signature validation impacts operation, and may 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 may 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.

When a signer digitally signs a widget package, or a validator validates a widget package, it MUST make sure that the following requirements on a widget signature apply to all widget signatures included in widget package:

• Each widget signature is a detached XML Signature that complies with [XMLDSIG11] syntax.

• Each widget signature is generated or validated in a manner compliant with [XMLDSIG11] processing rules.

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

• Each widget signature contains a dsp:Role signature properties element compliant with [XMLDSIG-Properties] and this specification.

• Each widget signature contains a dsp:Identifier signature properties element compliant with [XMLDSIG-Properties] and this specification.

• Every ds:Reference used within a widget signature has a URI attribute.

• Every ds:Reference used within a widget signature is one of the following two kinds of reference:

  Reference to content within the same ds:Signature element

  Every ds:Reference to an item within the widget signature uses an IDREF value for the ds:Reference 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 to a file entry is a zip relative path that identifies a file inside the widget package.

7.2. Author Signature

An author signature is a widget signature with a signature file name that adheres to the naming convention for an author signature and has an [XMLDSIG-Properties] Role element whose URI attribute is equivalent to the author role attribute value. An author signature is intended to be generated by the author of the widget. The author signature can be used to determine:

• the author of a widget,
• that the integrity of the widget is as the author intended,
• and whether two widgets came from the same author.

A widget package can contain zero or one author signatures.

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

Author Role Attribute value (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.

7.2.1. Naming Convention for an Author Signature

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.3. Distributor Signatures

A distributor signature is a widget signature with a signature file name that adheres to the naming convention for a distributor signature and has an [XMLDSIG-Properties] Role element whose URI is equivalent to the distributor role attribute value. A distributor signature is intended to be generated by a third party (a distributor) that is distributing the widget on behalf of the author. The distributor signature can be used to determine:

• that a particular distributor has distributed a widget package,
• and that the integrity of the widget package is as the distributor intended.

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

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

Distributor Role Attribute value (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 includes ds:References for every file entry of the widget package, including any author signature, but excluding any distributor signatures. In other words, distributor signatures countersign author signatures, but will not countersign other distributor signatures.

7.3.1. Naming Convention for a Distributor Signature

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

The dist-sig-filename 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
xml-suffix-string = %x2e.78.6d.6c

• The signature-string rule defines the lower-case 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 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.

7.4. X.509 Data

Every widget signature can have additional information contained in the signature ds:X509Data element, as specified by the [XMLDSIG11] specification. This can include X.509 certificates, and/or CRL and/or OCSP response information that, if included, are conveyed according to the [XMLDSIG11] specification.

The mandatory certificate format is the X.509 certificate format specified in [RFC5280]. For signers, the RECOMMENDED version of the certificate format is X.509 version 3.

A validator MUST support processing X.509 v3 certificates for when certificates are used in the ds:X509Data of a digital signature.

Note: v3 certificates are necessary to use the v3 extension to express the basic constraints on a certificate. This allows CA certificates to be distinguished from end entity certificates, enabling more robust trust verification.

7.5. Identifier Signature Property

A signer uses the dsp:Identifier signature property to uniquely identify the signature (for example, to enable signature management).

Note: Signing parties are expected to ensure that the dsp:Identifier signature property value is unique for the widget packages that they sign.

8. Algorithms

An implementation MUST follow the rules specified in [XMLDSIG11] regarding use of the following algorithms.

Note: Signing a widget with an optional algorithm can result in signatures that are not interoperable with implementations that do not support these algorithms. Authors are cautioned to take this into consideration when signing widget packages.

8.1. Signature Algorithms

This section defines the signature algorithms that this specification relies upon. The recommended key length of the key used to generate a signature is 2048 bits.

The following signature algorithms MUST be supported by a validator:

RSAwithSHA256:

http://www.w3.org/2001/04/xmldsig-more#rsa-sha256

DSAwithSHA1:

http://www.w3.org/2000/09/xmldsig#dsa-sha1

The following signature algorithms MUST be supported by a signer:

RSAwithSHA256:

http://www.w3.org/2001/04/xmldsig-more#rsa-sha256

It is OPTIONAL for a signer to support the following signature algorithm:

DSAwithSHA1:

http://www.w3.org/2000/09/xmldsig#dsa-sha1

The following signature algorithm SHOULD be supported by a signer and validator:

ECDSAwithSHA256:

http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256

This is ECDSA over the P-256 prime curve specified in Section D.2.3 of FIPS 186-3 [FIPS186-3] (and using the SHA-256 hash algorithm).

Note: Although not all validators may support this optional algorithm, implementation is encouraged since it may become mandatory in a subsequent release of this specification. This may also be necessary if any security issues are discovered with the currently required algorithm.

It is OPTIONAL for an implementation to support additional signature algorithms.

8.2. Digest Algorithms

The following digest algorithms MUST be supported by an implementation:

SHA-256:

http://www.w3.org/2001/04/xmlenc#sha256

It is OPTIONAL for an implementation to support additional digest algorithms.

8.3. Canonicalization Algorithms

The following canonicalization algorithms MUST be supported by an implementation:

Exclusive XML Canonicalization 1.0 (omits comments) [XML-exc-C14N]:

http://www.w3.org/2001/10/xml-exc-c14n#

It is OPTIONAL for an implementation to support additional canonicalization algorithms.

9. Processing Rules

9.1. Locating and Processing Digital Signatures in a Widget Package

This section defines for how to locate signature files in a widget package for the purpose of signature validation.

An implementation MUST perform a case-sensitive comparisons on file names.

1. Let signatures be an empty list.

2. For each file entry at the root of the widget package, if the file name matches the naming convention for a distributor signature then append this file entry to the signatures list.

3. If the signatures list is not empty, sort the list of signatures by the file name in ascending numerical order.

   For example, signature1.xml followed by signature2.xml followed by signature3.xml and so on.

   As another example, signature9.xml followed by signature44.xml followed by signature122134.xml and so on.

4. Search the root of the widget package for any file name that matches the naming convention for an author signature and then append this file entry to the signatures list.

5. If the signatures list is empty (meaning no signature files were found), terminate this algorithm and treat this widget package as an unsigned widget package.

6. Validate the signature files in the signatures list in descending numerical order, with distributor signatures first (if any).

   For example, validate signature3.xml, then signature2.xml, then signature1.xml and lastly author-signature.xml.

   As another example, validate signature122134.xml, then signature44.xml, and then signature9.xml, and lastly author-signature.xml.

   The decision of which (if any) distributor signatures are to be validated and whether the author signature is validated is out of scope of this specification. This MAY be determined by the security policy used by the validator.

   Numerical order 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.

   Note: Ordering of widget signature files by the numeric portion of the file name can be used to allow consistent processing and possible optimization.

9.2. Common Constraints for Signature Generation and Validation

This section defines a set of common constraints for signature generation and validation.

When validating a signature, a validator MUST verify each condition is met (as indicated by the [RFC2119] keywords) and treat the signature as being in error if any constraint is violated.

When generating a signature, a signer MUST generate the appropriate content in the signature document as required by the algorithm below (as indicated by the [RFC2119] keywords within the algorithm).

The set of constraints are as follows:

1. A widget signature MUST have a ds:Reference for every file entry that is not a widget signature.

2. A distributor signature MUST have a ds:Reference for any author signature, if one is present within the widget package.

3. For each ds:Reference element:

   1. For references that are not same-document references, the URI attribute MUST be a zip relative path from the root of the widget package to the file entry being referenced.

   2. The Algorithm attribute of the ds:digestMethod MUST be one of the digest algorithms.

   3. A ds:Reference to same-document XML content MUST have a ds:Transform element child that specifies the canonicalization method. Canonical XML 1.1 MUST be specified as the Canonicalization Algorithm for this transform. A ds:Reference that is not to same-document XML content MUST NOT have any ds:Transform elements.

      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 algorithm Canonical XML 1.0 will be used, as specified in XML Signature 1.1.

      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 , the result of dereferencing the URI-Reference MUST be an octet stream. In particular, an XML document identified by URI is not parsed by the signature application unless the URI is a same-document reference or unless a transform that requires XML parsing is applied." In the same section the specification notes, "In this specification, a ‘same- document’ reference is defined as a URI-Reference that consists of a hash sign (‘#’) followed by a fragment or alternatively consists of an empty URI…" [XMLDSIG11].

4. Every Signature Property required by this specification is to be incorporated into the signature as follows:

   1. A widget signature MUST include a ds:Object element within the ds:Signature element. This ds:Object element MUST have an Id attribute that is referenced by a ds:Reference element within the signature ds:SignedInfo element.

   2. This ds:Object element MUST contain a single ds:SignatureProperties element that MUST contain a different ds:SignatureProperty element for each property required by this specification.

   3. Each ds:Signature property required by this specification MUST meet the syntax requirements of [XMLDSIG-Properties].

5. The ds:Signature needs to meet the following requirements:

   1. The Algorithm attribute of the ds:CanonicalizationMethod element MUST be one of the canonicalization algorithms.

   2. The ds:SignatureMethod algorithm used in the ds:SignatureValue element MUST be one of the signature algorithms. The ds:Signature MUST be produced using a key of the recommended key length or stronger (meaning larger than 2048 bits).

   3. The ds:KeyInfo element MAY be included, which MAY include CRL and/or OCSP information in a manner compliant with the [XMLDSIG11] specification.

   4. If one or more certificates are in the ds:KeyInfo element, they MUST be of the mandatory certificate format.

   5. The ds:SignedInfo element MUST include all the ds:Reference elements listed in items 1, 2 and 4 of this section.

6. The widget signature MUST be serialized as a [UTF-8] encoded [XML] document and be named using the appropriate naming convention: either the naming convention for a distributor signature or the naming convention for an author signature.

10. Security Considerations

This section is non-normative.

The signature scheme described in this document deals with the content present inside a potentially compressed widget package. This implies that, in order to verify a widget signature, implementations need 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 needs to be taken to avoid resource exhaustion attacks through maliciously crafted widget packages during signature validation.

Implementations need to 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.

There is no single signature file that includes all files of a widget package, including all of the signature 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 the signature and any distributor signatures, if they are present. A signature file can also be renamed, which can affect the order in which distributor signatures are processed.

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

Acknowledgements

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

Normative References

[ABNF]

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

[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

[RFC2119]

Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. IETF, March 1997. http://www.ietf.org/rfc/rfc2119

[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

[UTF-8]

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

[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

[Widgets Packaging]

Widget Packaging and Configuration, M. Cáceres. W3C Candidate Recommendation. http://www.w3.org/TR/widgets/

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

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

[XMLDSIG11]

XML Signature Syntax and Processing, Version 1.1, D. Eastlake, J. Reagle, D. Solo, F. Hirsch, T. Roessler, K Yiu. W3C Working Draft 04 February 2010. http://www.w3.org/TR/2010/WD-xmldsig-core1-20100204/

[XMLDSIG-2ndEd]

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

[XMLSecAlgs]

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, F. Hirsch, W3C Working Draft 04 February 2010. http://www.w3.org/TR/2010/WD-xmldsig-properties-20100204/

[XML-Schema-Datatypes]

XML Schema Part 2: Datatypes W3C Recommendation, P. Biron, A. Malhotra. May 2001. http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/

[ZIP]

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

Informative References

[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

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

[Test-Methodology]

A Method for Writing Testable Conformance Requirements. D. Hazaël-Massieux and M. Cáceres. W3C Working Group Note 28 January 2010 http://www.w3.org/TR/test-methodology/