Widgets 1.0: Digital Signature

Editor's Draft 27 May 2008

This Version:: ~~http://www.w3.org/TR/2008/WD-widgets-digsig-20080527/~~
Latest Version:: http://www.w3.org/TR/widgets-digsig/
Latest Editor's Draft:: http://dev.w3.org/2006/waf/widgets-digsig/
Version history:: Twitter messages (non-editorial changes only): http://twitter.com/widgetspecs (RSS)
Editor:: Marcos Caceres, Invited Expert

Abstract

This document defines a profile of the XML-Signature Syntax and Processing specification to allow a widget resource to be digitally signed. Vendors and authors can digitally sign widgets as a trust and quality assurance mechanism. Prior to instantiation, a widget user agent can use the digital signature to verify the authenticity and data integrity of the files in a widget resource. In the rare case where a widget damages the end-user's device, the digital signature may provide a user with legal recourse to prove that a widget resource was signed by a particular author or publisher.

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

This document is produced the Web Application Formats (WAF) Working Group (WG). This WG is part of the Rich Web Clients Activity and this activity is within the W3C's Interaction Domain.

This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy.

This document is produced by the Web Application Formats WG, part of the Rich Web Clients Activity in the W3C Interaction Domain. It is expected that this document will progress along the W3C's Recommendation track. 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.

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. Please send comments to public-appformats@w3.org, the W3C's public email list for issues related to Web Application Formats. Archives of the list are available. A detailed list of changes from the previous version is also available from the W3C's CVS server.

Implementers should be aware that this document is not stable. Implementers who are not taking part in the discussions are likely to find the specification changing out from under them in incompatible ways. Vendors interested in implementing this document before it eventually reaches the Candidate Recommendation stage should join the aforementioned mailing lists and take part in the discussions.

1. Introduction
- 1.1 Signature Profile
- 1.2 Namespaces
2. Conformance
3. Definitions
4. Procedure for Signing a Widget Resource
5. Procedure for Verifying a Digital Signature
Acknowledgements
References

1. Introduction

Digitally signing a widget resource involves signing all of its file entries using a unique private key that is known only to the signer. The resulting detached XML Signature is included at the root of a widget resource under the name signature.xml (case insensitive). This XML Signature must include the signer's X.509 Certificate in KeyInfo.

Example of a signature.xml document:

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

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#">
	<SignedInfo>
		<CanonicalizationMethod
			Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
		<SignatureMethod
			Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />

		<Reference URI="config.xml">
			<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
			<DigestValue>j6...8nk=</DigestValue>
		</Reference>

		<Reference URI="index.html">
     		<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
     		<DigestValue>lm...34=</DigestValue>
		</Reference>

		<Reference URI="icon.png">
			<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
			<DigestValue>pq...56=</DigestValue>
		</Reference>

	</SignedInfo>
	<SignatureValue>MC0E~LE=</SignatureValue>
	<KeyInfo>
		<X509Data>
			<X509Certificate>MI...lVN</X509Certificate>

		</X509Data>
	</KeyInfo>
</Signature>

1.1 Signature Profile

This specification profiles XML Signature Syntax and Processing Specification [XMLDsig] for widget signing as follows:

Every file entry in a widget resource must be signed. The resulting digital signature must be serialized into an UTF-8 encoded XML document and placed at the root of the widget archive under the name signature.xml.
Reference elements must use the SHA1 as the digest method.
The signature method to produce the SignatureValue must be RSA-SHA1.
A KeyInfo element must be present and the digital certificate format must conform to the [X509v3] specification. Implementations must be prepared to accept all X.509 certificates versions identified in [X509v3] via the version field. To be clear, the value of the version field identifies the version of an X.509 certificate in the following way:
- 0 is X.509 version 1,
- 1 is X.509 version 2,
- 2 is X.509 version 3,
- If the version field is omitted, then the X.509 version is 1.
SignatureProperties elements are ignored by this specification, but they may be present in a signature document.

(For SignatureProperties, we are considering defining one element: WidgetSigningProfile, with a version parameter. All of which would be signed.)

<SignatureProperties><WidgetSigningProfile version="1.0"></SignatureProperties>

May allow signature chains.

Put the transform back in.

1.2 Namespaces

All elements in this specification operate within the namespaces specified in [XMLDsig]. This specification does not define any additional namespaces.

2. Conformance

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

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

There are two classes of product that can claim conformance to this specification:

A digital signature document.
A widget user agent

Products that generate a digital signature document must generate XML documents that conform to [XMLDsig] and adhere to the restrictions imposed by this specification.

Products that check the conformance of a digital signature document must not claim conformance to this specification, though they can claim to verify that a digital signature document conforms to this specification.

A widget user agent must behave as described by this specification in order to claim conformance, specially when faced with an invalid widget resource or a non-conforming digital signature document.

3. Definitions

A widget resource is a byte-stream or file that conforms to section 4.0 and section 5.0 of the [Widgets Packaging] specification.

A file entry is the amalgamation of data held by a local file header, file data, and (optional) data descriptor [ZIP] for each physical file stored in a zip archive.

A digital signature document is a well-formed XML document named signature.xml generated by applying the procedure for signing a widget resource described in this document. The document will conform to [XMLDsig].

An invalid zip archive in this specification is one where the digital signature document is either in error, or there is a mismatch between the data in the digital signature document and/or the data in a file entry (meaning that the authenticity or data integrity of the zip archive could not be verified). For rules on dealing with invalid zip archives, please see the "Dealing with Invalid Zip Archives" section in the [Widgets Packaging] specification.

A digitally signed widget resource is one that contains a file entry with a file name field that matches 'signature.xml' in any case form, though the lower case form is recommended. The signature.xml document must contain a Reference element for every file entry in the widget resource. In addition, the file data of the file entry must conform to [XMLDsig], but in accordance to the procedure for signing a widget resource.

A decompressed representation of a file entry is the data extracted from the data field of a local file header (and decompressed using [Deflate] when the compression method field is 8).

4. Procedure for Signing a Widget Resource

The procedure for signing a widget resource to produce a conforming digital signature document is as follows. Implementations may perform the following algorithm in an alternative manner so long so long as the end result is indistinguishable from the result that would be obtained by the following the specification.

If the widget resource contains zero file entries, treat this zip archive as an invalid zip archive.
Create a SignedInfo element [XML].
For each file entry in the widget resource, if the file name field of the local file header of the file entry does not case insensitively match signature.xml:
1. Let path be the value of the file name field of the local file header.
2. If general purpose bit 11 of the local file header is 0, then convert the character encoding of path from [CP437] to [UTF-8].
3. Verify that path is a valid zip-relative-path, as defined in [Widgets Packaging].
4. Create a Reference element.
5. Create a URI attribute in the Reference element and assign it the value of path.
6. Let hash-value be the digests of applying the SHA-1 algorithm to the file entry's decompressed representation (see [XMLDsig] for how to do this).
7. Create a DigestValue element and append the hash-value as a Text node.
8. Create a DigestMethod element with an Algorithm attribute, and give that attribute the value http://www.w3.org/2000/09/xmldsig#sha1.
9. Append this Reference element to the SignedInfo element.
Create a CanonicalizationMethod element and set the value of its Algorithm attribute to http://www.w3.org/TR/2001/REC-xml-c14n-20010315.
Create a SignatureMethod element and set the value of its Algorithm attribute to http://www.w3.org/2000/09/xmldsig#rsa-sha1.
Calculate the digest of the SignedInfo element using RSA-SHA1 [XMLDsig], sign it and place the signature in the <SignatureValue> element.
Place the signer's certificate in the KeyInfo element.
Create a Signature element in the http://www.w3.org/2000/09/xmldsig# namespace.
Place the SignedInfo, SignatureValue, and KeyInfo elements into the Signature element.
Open the zip archive so that a file entry can be written (eg. as a buffered output stream).
Serialize the Signature element and all its children into a UTF-8 encoded XML file in canonical form and save it in the root of the widget resource as signature.xml overriding the contents of any existing signature.xml file entry.

5. Procedure for Verifying a Digital Signature

The procedure for verifying a widget signature is to validate the XML Signature according to [XMLDsig], including Reference digest validation. Successful widget signature validation requires verifying that the XML Signature includes a Reference element for every decompressed representation of a file entry in the widget resource and that each Reference hash validates. When general purpose bit 11 of the local file header of a file entry is not set, then the value derived from the file name field must be converted from [CP437] to [UTF-8] when validating.

Care should be taken not to write the decompressed representation to disk or otherwise treat the decompressed representation as valid and trusted until the security checks have been successfully completed.

Need to add other security considerations here (eg protecting against decompressed representations that are too large for the device to handle).

Acknowledgements

This section will be completed as the document matures.

References