W3C

Widgets 1.0: Digital Signatures

W3C Working Draft 30 April Candidate Recommendation 12 June 2009

This Version:
http://www.w3.org/TR/2009/WD-widgets-digsig-20090430/ http://www.w3.org/TR/2009/CR-widgets-digsig-20090612/
Latest Version:
http://www.w3.org/TR/widgets-digsig/
Previous Versions:
http://www.w3.org/TR/2009/WD-widgets-digsig-20090430/
http://www.w3.org/TR/2009/WD-widgets-digsig-20090331/
http://www.w3.org/TR/2008/WD-widgets-digsig-20080414/
 
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:
Frederick Hirsch, Nokia
Marcos Caceres Cáceres , Opera Software ASA
Mark Priestley, Vodafone

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 is the 12 June 2009 Candidate Recommendation of the Widgets 1.0: Digital Signature specification. W3C publishes a Candidate Recommendation to indicate that the document is believed to be stable and to encourage implementation by the developer community. The Web Applications (WebApps) Working Group expects to request that the Director advance this document to Proposed Recommendation once the Working Group has developed a comprehensive Widgets 1.0: Digital Signature test suite, and demonstrated at least two interoperable implementations for each test. The WebApps Working Group expects to show these implementations by September 2009. The Working Group does not plan to request to advance to Proposed Recommendation prior to 01 September 2009.

Publication as a Working Draft Candidate Recommendation 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 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 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 is the 30 April 2009 Last Call Working Draft version of the "Widgets 1.0 Digital Signature Specification". The Last Call period ends on 1 June 2009. 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 Introduction

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.

A widget package can be signed by the author of the widget producing an [XMLDSIG11] signature that cryptographically includes all of the file entries other than signature file s. 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 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 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:

For resources not under the control 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 in the ds11: namespace
http://www.w3.org/2009/xmldsig11
Individual Signature Properties [XMLDSIG-Properties] such as Role are defined in the dsp: namespace
http://www.w3.org/2009/xmldsig-properties
Algorithms used by XML Security are defined in a number of places, including XML Signature 1.1.
See the XML Security Algorithm Cross-Reference for details [ XMLSecAlgs ].

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.2 Definitions

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

A file entry is the compressed (or Stored [ZIP] ) representation of a physical file or folder contained within a widget package , as defined in the [Widgets Packaging] specification.

The root of the widget package is the top-most path level of the widget package that can logically 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. 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 file s. 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 (as profiled in this specification) whose file name follows the naming conventions of a signature file name .

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 signature signatures s and distributor signature s. signatures .

A widget signature is an [XMLDSIG11] signature, as contained in a signature file .

An author signature is a widget signature with a widget 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 a widget (i.e., the person who authored the widget).

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 the distributor of a widget (i.e., a third party that is distributing the widget on behalf of the author).

A wall clock timestamp is defined in the [XMLDSIG-Properties] specification.

A zip relative path MUST conform to the [ABNF] for zip-rel-path as specified in [Widgets Packaging] .

1.3 Conventions

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:

This is an example containing some code
if (a <> 1234122){ //...do something }

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.4 Example

This section is non-normative.

Example of a distributor signature document, named signature1.xml :

<?xml version="1.0" encoding="UTF-8"?>
<Signature xmlns="http://www.w3.org/2000/09/xmldsig#" 
  Id="DistributorASignature">
 <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">
   <DigestMethod 
    Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
   <DigestValue>...</DigestValue>
  </Reference>
 </SignedInfo>
 <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>  
 <SignatureValue>...</SignatureValue>
 <KeyInfo>
        <X509Data>
         <X509Certificate>...</X509Certificate>
        </X509Data>
 </KeyInfo>
</Signature>

2 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:

In particular, this specification explicitly supports both author signature signatures s and distributor signature s. 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] .

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:

Products that generate a widget signature MUST generate [XML] documents that conform to [XMLDSIG11] and conform to this specification.

A user agent is an implementation that attempts to support this specification. A user agent MUST behave as described by this specification in order to claim conformance.

Implementers are encouraged to provide mechanisms to enable end-users to install certificates for enabling verification of digital signatures within the widget package.

4 Locating and Processing Digital Signatures for the Widget

This section defines how to locate signature files in a widget package for processing. An implementation MUST achieve the same result as the following algorithm used to locate signature files in a widget package :

  1. Let signatures be an empty list.

  2. For each file entry in 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. An Implementation MUST perform a case-sensitive comparison.

  3. If the signatures list is not empty, sort the list of signatures by the file name field in ascending numerical order (e.g. signature1.xml followed by signature2.xml followed by signature3.xml etc).

  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. An Implementation MUST perform a case-sensitive comparison.

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

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

    The decision of which (if any) distributor signature signatures s 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 user agent.

    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.

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

  7. Every signature that is verified MUST be verified according to Signature Verification defined in this specification.

5 Signature Syntax and use in Widget Packages

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 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 widget package is signed according to this specification, the following requirements on a widget signature apply to any widget signature included in widget package :

5.2 Author Signature

The author signature can be used to determine:

A widget package MAY contain zero or one author signature s. signatures .

In addition to the requirements on a widget signature , the following MUST be true of an author signature ‘ s 's [XMLDSIG-Properties] Role element ’s 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 .

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

A file matching the author-sig-filename [ABNF] rule MUST contain a dsp:Role signature property having the URI for an Author role as defined in this specification or the signature MUST be flagged as being in error.

5.3 Distributor Signatures

The distributor signature can be used to determine:

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

In addition to the requirements on a widget signature , the following MUST be true of an distributor signature ‘ s 's [XMLDSIG-Properties] Role element ’s 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 MUST include ds:Reference s for every file entry of the widget package , including any author signature , but excluding any distributor signature s. signatures . In other words, distributor signature s MUST countersign author signature s, signatures , but MUST NOT countersign other distributor signature s. signatures .

5.3.1 Naming Convention for a Distributor Signature

Each distributor signature MUST have 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 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
xml-suffix-string
=
%x2e.78.6d.6c

An example is "signature20.xml".

Leading zeros are disallowed in the numbers.

A file entry whose file name does not match the above ABNF MUST be ignored, meaning that an implementation MUST NOT treat the file entry as a signature file .

For example, a file with the file name " signature01.xml " will be ignored.

It is OPTIONAL that the signature file name s of distributor signature signatures s form a contiguous set of numeric values.

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

Thus, for example, signature2.xml precedes signature11.xml .

A file matching the dist-sig-filename [ABNF] rule MUST contain a dsp:Role signature property having the URI for a Distributor role as defined in this specification or the signature MUST be flagged as being in error.

5.4 X.509 Data

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

The X.509 certificate format MUST be supported when certificates are used in the ds:X509Data . This is the mandatory certificate format . The RECOMMENDED version of the certificate format is X.509 version 3 as specified in [RFC5280] . Implementations MUST be prepared to accept X.509 v3 certificates [RFC5280] .

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.

5.5 Identifier Signature Property

The signer uses the dsp:Identifier signature property to uniquely identify the signature to enable signature management. It MUST be unique for a given signer. Signing parties are expected to ensure that the dsp:Identifier signature property value is unique for the widget packages that they sign.

6 Algorithms

Definitions of the algorithm URI identifiers specified in [XMLDSIG11] take precedence if there is any difference in this document. Rules specified in [XMLDSIG11] 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:
http://www.w3.org/2001/04/xmldsig-more#rsa-sha256
DSAwithSHA1:
http://www.w3.org/2000/09/xmldsig#dsa-sha1
REQUIRED for signature verification, OPTIONAL for generation

The following signature algorithms SHOULD be supported:

ECDSAwithSHA256:
http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256
Note that this
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 all implementations may not 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.

A user agent MAY support additional signature algorithms.

The RECOMMENDED key length ( recommended key length ) of the key used to generate the signature is 2048 bits. The key length of the key used to generate the signature MUST NOT be less than 1024 bits. The signer MUST NOT generate signatures using key lengths of less than 2048 bits unless the life time of the signature is less than one year.

6.2 Digest Algorithms

The following digest algorithms MUST be supported:

A user agent MAY support additional digest methods.

6.3 Canonicalization Algorithms

The following canonicalization algorithms MUST be supported:

A user agent MAY support additional XML canonicalization methods.

7 Processing Rules

7.1 Common Constraints for Signature Generation and Validation

The following constraints apply to both Signature Generation and Signature Verification . These constraints MUST be observed when generating a widget signature and MUST be verified as met when validating a widget signature .

  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. 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. The ds:Reference MUST NOT have any ds:Transform elements.

  4. Every Signature Property required by this specification MUST 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 MUST 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 and MAY include certificate, CRL and/or OCSP information. If so, it MUST be compliant with the [XMLDSIG11] specification. If certificates are used, they MUST conform to the mandatory certificate format .

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

7.2 Signature Generation

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

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

A unique identifier string for the signature MUST be placed in the dsp:Identifier signature property by the signer. This MUST be a unique signing string for all widget signature signatures s created by the signer. Signing parties are expected to ensure that the dsp:Identifier signature property value is unique for the widgets that they sign.

7.3 Signature Verification

A widget signature MUST be validated according to Core Validation, as defined in XML Signature [XMLDSIG11] , including Reference Validation and Signature Validation.

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

If a ds:KeyInfo element is present, then it MUST conform to the [XMLDSIG11] specification. If present, the user agent MUST perform Basic Path Validation [RFC5280] on the signing key and SHOULD perform revocation checking as appropriate.

If widget signature validation is successful any external entities (e.g., a user agent that implements [Widgets Packaging] relying on the validation of the widget signature MUST be notified of the success.

If widget signature validation fails for any reason, any external entities (e.g., a user agent that implements [Widgets Packaging] ) relying on the validation of the widget signature MUST be notified of the failure. This specification does not define the means or format of a failure notification, which is left up to implementers. The reason 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 and CRL/OCSP verification.

8 Security Considerations

This section is non-normative.

The signature scheme described in this document deals with the content present inside a 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 should 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.

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 signature signatures s can be removed or added. An author signature could also be attacked by removing it and any distributor signature signatures s if they are present. A signature file may also be renamed, which can affect the order in which distributor signatures are processed.

Mechanisms to install new root certificates in a user agent should 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 earlier drafts of this document.

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 . W3C Recommendation. , J. Boyer, M. Marcy. 2 May 2008. 2008, W3C Recommendation. http://www.w3.org/TR/2008/REC-xml-c14n11-20080502/
[FIPS186-3]
DRAFT FIPS PUB 186-3 . Digital Signature Standard (DSS). U.S. Department of Commerce/National Institute of Standards and Technology.
http://csrc.nist.gov/publications/drafts/fips_186-3/Draft_FIPS-186-3%20_November2008.pdf
[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
[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]
Widgets 1.0: Packaging and Configuration , M. Caceres. Cáceres. W3C Working Draft 29 April 28 May 2009. This is an Editors Working Draft, a work in progress, and subject to change. http://www.w3.org/TR/2009/WD-widgets-20090528/
[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/
[XML]
Extensible Markup Language (XML) 1.0 (Third Edition) ,T. Bray, J. Paoli, C. M. Sperberg-McQueen, E. Maler, F. Yergeau. W3C, February 2004.
[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 et al. W3C Working Draft, 26 February 2009. http://www.w3.org/TR/2009/WD-xmldsig-core1-20090226/
[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 26 February 2009. http://www.w3.org/TR/2009/WD-xmlsec-algorithms-20090226/
[XMLDSIG-Properties]
XML Signature Properties ,F. Hirsch, W3C Working Draft 30 April 2009. http://www.w3.org/TR/2009/WD-xmldsig-properties-20090430/
[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]