This document defines a profile of the XML Signature Syntax and Processing 1.1 specification to allow a widget package to be digitally signed. Authors and distributors can digitally sign a widget as a mechanism to ensure continuity of authorship and distributorship. A user agent, or other validation system, can use a digital signature to verify the data integrity of the files within a widget package and to confirm the signing key(s).
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
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 .
public is encouraged to send
comments to the WebApps Working Group's public mailing
). 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. IMPORTANT: By the time the Last
Call comment period ends (June 28), the Working Group
expects to have data that at
least two independent implementations pass 100% of this spec's test
suite . As such, if no substantive changes must be made as a result
of the Last Call review, we will not publish a Candidate
Recommendation for this
spec and the next publication will be
Proposed Recommendation .
This document is produced by the Web Applications WG , part of the 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 .
A user agent or other entity can use an author signature to determine:
A widget package can also be signed by one or more distributors to produce a signature file that cryptographically includes all non-signature files as well as any author signature (if one was included). In this specification, this kind of signature is referred to as a distributor signature . To be clear, distributor signatures countersign author signatures , but do not countersign other distributor signatures . Because of this, an author signature needs to be included in a widget package before a distributor signature or the validation process defined in this specification will fail.
A user agent or other entity can use a distributor signature to determine:
The complete signing model is illustrated in Figure 1 .
This document addresses the following requirements from the [Widgets Requirements] document:
Support for Multiple Message Digest Algorithms : this
specification supports SHA-256, the
Key Usage Extension : part of X.509v3.
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 , the examples and notes, and security considerations in this specification are non-normative. Everything else in this specification is normative.
A signer is a user agent that implements [XMLDSIG11] and digitally signs a widget package in a manner that conforms to the requirements of this specification and in a manner that conforms to the applicable generation requirements of [Signature Properties] .
A validator is a user agent that implements [XMLDSIG11] and validates the signature files of a widget package in a manner that conforms to the requirements of this specification and in a manner that conforms to the applicable validation requirements of [Signature Properties] .
Note: User agents that implement this specification are encouraged to allow end-users to install digital certificates. This allows the verification of digital signatures within the widget package for when custom root certificates are not shipped with a runtime (e.g., for beta testing purposes).
As the following terms are used 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
The XML namespace for [XML] elements used by
this specification is
The profile URI for this
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.
This specification relies on a user agent's conformance to [XMLDSIG11] for support of signature algorithms, certificate formats, canonicalization algorithms, and digest methods. As this specification is a profile of [XMLDSIG11] , it makes a number of recommendations as to what signature algorithms should be used when signing a widget package to achieve optimum interoperability. See Signature Algorithms of [XMLDSIG11] for the list of required algorithms.
The recommended key lengths are:
The recommended digest method is SHA-256 .
The recommended certificate format is X.509 version 3 as specified in [RFC5280] .
This section is informative.
A signature file can have
information contained in a
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. X.509 v3
certificates provide means to express the basic constraints on a
certificate. This allows CA certificates to be
distinguished from end entity certificates, enabling more robust
trust verification. See also [RFC5280] for
An author signature is a
signature file whose file name adheres to the naming convention for
an author signature and whose [Signature Properties]
value is equal to the author role
URI . An author signature is
intended to be generated by the author of
the widget, which is the entity or entities whom claim authorship
over the content of the widget
author-sig-filename = %x22.214.171.124.6f.72.2d.126.96.36.199e.188.8.131.52.65.2e.78.6d.6c
A distributor signature is
a signature file whose file name adheres to the naming convention
for a distributor signature and whose [Signature Properties]
value is equal to the distributor
role URI . A distributor
signature is intended to be generated by a distributor , which is a third party that is
distributing the widget on behalf of the author.
Each distributor signature
has a file name consisting of the
" 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
dist-sig-filename = signature-string non-zero-digit *DIGIT xml-suffix-string signature-string = %x184.108.40.206e.220.127.116.11.65 non-zero-digit = %x31-39 xml-suffix-string = %x2e.78.6d.6c
signature-string rule defines the lower-case
non-zero-digit rule defines a digit in the
1-9 , thus leading zeros are disallowed by this
DIGIT is defined as a digit in the range
xml-suffix-string rule defines the lower-case
An example is
The algorithm below relies on the signature generation rules of [XMLDSIG11] (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 RECOMMENDED that a signer use the recommended canonicalization algorithm , the recommended signature algorithm , the recommended key lengths for the appropriate algorithm, and the recommended certificate format .
The algorithm to generate a digital signature is as follows:
Using the Processing
Rules of [XMLDSIG11] , perform
reference generation for each file of the
widget package that is not a signature file . Set the a
attribute of each
ds:Reference to be the zip relative path that identifies the
file inside the widget package .
Optionally, include a
ds:KeyInfo element in the
manner described in [XMLDSIG11] (see
KeyInfo Element for how to do this). The element
can include CRL and/or OCSP information [RFC5280] (see note about X.509
data in this specification).
Otherwise, if generating a distributor signature :
a reference to the
ds:Object that contains the
signature properties created in the steps above.
Serialize the signature as a [UTF-8] encoded [XML] document using the 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: It is not a requirement that the file names of distributor
signatures are serially numbered
signature3.xml , and so
on. A signer can to use
whatever pattern they want, so long as the file name conforms to
convention for a distributor signature . The numeric part of
the file name affects the order in which signature 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 , assign a
number greater than that of all the other distributor
signatures for the numeric part of the distributor
signature's file name.
This section is non-normative.
The following is an example of a distributor signature document, named
signature1.xml . For legibility, the example omits the
content of the various cryptographic digests and instead uses
<?xml version="1.0" encoding="UTF-8"?> <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>
The algorithm below relies on the Core Validation of [XMLDSIG11] (Section 3.2) and the various validation rules defined in [Signature Properties] (links to the appropriate sections of those specifications are provided where needed for validation). This specification does not define the means or format of a failure notification: handling of signatures that are in error is left up to the implementation. 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. 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 .
During validation , a user agent MAY treat a widget package as being in error if it deems that the key length for a signature algorithm to is not large enough to be secure (e.g., under 2048 bits for RSA and DSA , or 224 bit for ECDSA ).
The algorithm to validate digital signatures is as follows:
Let signatures list be the result of applying the algorithm to locate signature files in a widget package .
If the signatures list is empty (meaning no signature files were found in the widget package), terminate this algorithm and treat the widget package as an unsigned widget package: It is left up to the user agent to decide how to treat unsigned widget packages.
For each signature in signatures list :
Check that signature has a single same-document
ds:Reference to a
ds:Object container for
[Signature Properties] in
accordance with the Signature Properties Placement section of
[Signature Properties] .
If signature 's file name matches the naming convention for an author signature , validate the role property against the author role URI . If the role property is missing or or invalid, then signature is in error .
If all signatures validate successfully, treat this as a signed widget package. It is left up to the user agent to decide how to treat singed widget packages.
The algorithm to locate signature files in a widget package is as follows. This algorithm makes use of the concept of numerical order , which is the order based on the numeric portion of a distributor signature's file name . Thus in the case more than one distributor signature is to be processed, the highest numbered distributor signature is ordered first.
Let signatures be an empty list.
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.
This section is non-normative.
In addition to the security considerations described in this section, the Security Considerations of [XMLDSIG11] 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 . This implies that, in order to verify a signature file , a user agent needs to decompress a data stream that can come from an arbitrary source.
Care needs to be taken to avoid resource exhaustion attacks through maliciously crafted widget packages during signature validation.
Because 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.
If the user agent supports installing a new root certificate, an end-user should be made aware of what they are doing, and 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
Security policy is out of scope of this specification but has
important implications for signature file processing.
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.