Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
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.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.
This is the W3C First Public Working Draft of the Widgets 1.0: Digital Signature. 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.
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 signature, along with the signer's digital certificate, is
structured into an XML document, and included at the root of a widget
resource under the name signature.xml
.
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>
The signature scheme defined in this specification imposes a number of restrictions on the XML-Signature Syntax and Processing Specification [XMLDsig]:
signature.xml
.Reference
elements must use the SHA1
as the digest method.SignatureValue
must be RSA-SHA1.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,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.)
Note: The intention of these restrictions is to define a light-weight profile of [XMLDsig] that does not require widget user agents to implement [XPath].
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:
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.
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 a 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
).
The procedure for signing a widget resource to produce a conforming digital signature document is as follows:
SignedInfo
element.signature.xml
:
0
, then
convert the character encoding of path from [CP437] to [UTF-8].Reference
element.URI
attribute in the Reference
element and assign it the value of path.DigestValue
element and append the
hash-value as a Text
node.DigestMethod
element with an
Algorithm
attribute, and give that attribute the value
http://www.w3.org/2000/09/xmldsig#sha1
.Reference
element to the
SignedInfo
element.CanonicalizationMethod
element and set the value
of its Algorithm
attribute to
http://www.w3.org/TR/2001/REC-xml-c14n-20010315
.SignatureMethod
element and set the value of its
Algorithm
attribute to
http://www.w3.org/2000/09/xmldsig#rsa-sha1
.SignedInfo
element using
RSA-SHA1, sign it and place the signature in the
<SignatureValue>
element.KeyInfo
element.Signature
element in the
http://www.w3.org/2000/09/xmldsig#
namespace.SignedInfo
, SignatureValue
, and
KeyInfo
elements into the Signature
element.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.The procedure for verifying a digital signature is as follows. The algorithm first checks the validity of the digital signature and then verifies that all resources in a widget resource.
If a steps results in a false
condition or is otherwise
in error, then a widget user agent must treat the widget resource as an invalid zip archive and all processing of the widget
resource must stop.
signature.xml
.signature.xml
into a DOM tree using a valid XML Parser to
check that the document is well-formed [XML].Signature
element exists and it contains a
SignedInfo
element.Reference
element in the
SingedInfo
element:
0
, then convert
the character encoding of path from [CP437] to [UTF-8].file:///temp/widget/
)This section will be completed as the document matures.
This section will be completed as the document matures.