Copyright © 2008 W3C® (MIT, ERCIM, Keio), All Rights Reserved. W3C liability, trademark and document use rules apply.
This document is an editors' copy that has no official standing.
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/.
A proof of concept implementation of this specification in Perl is available from W3C. That implementation is believed to cover the MUSTs of this specification, with the notable exception of the PKIX trust model. Also, there is no support yet for special treatment of frame sets.
This specification is intended as a starting point for broader discussion. It makes a number of choices that are likely to be revisited. In particular, the choice of Canonical XML 1.0 [XMLC14N] as the only canonicalization algorithm, and the choice of SHA-1 as the only digest method (and RSA-SHA1 as the signature algorithm), is driven by the choice of widely deployed algorithms at the time of writing. Also, this specification most likely overconstrains those mechanisms of XML Signature that are used to add explicit signature semantics. We hope to explore these points as future work progresses.
1 Overview
2 Namespaces
3 Linking a signature from an HTML document
4 XML Signature Profile
4.1 Simple Profile
4.2 Full Profile
4.3 Signature Validity Model
4.4 Signature Key Information
4.5 Selection of cryptographic algorithms
5 HTTP Considerations
6 Examples
6.1
Simple signing example
6.2
Full signing example
6.3 This Document
7 Credits
8 References
Web security mechanisms based on TLS provide both confidentiality and integrity protection services. As a side effect, there is currently no broadly deployed way to provide integrity protection and authentication for documents on the Web in a way that is compatible with Web caching. At the same time, preserving information about the security state of information retrieved from the Web beyond one particular browsing session continues to be an area of active research and standards work. A number of common use cases would benefit from an easily deployable system for persistent authentication of Web content, including the distribution of court decisions and other high-value documents which must not be relied upon if changed.
This specification defines a mechanism for discovering XML Signatures associated with HTML documents and their dependent content. It further describes a constrained profile for use of XML Signature with Web Content, and the requisite semantics.
This specification does not stipulate any requirements for signature verification user interfaces. However, we refer the reader to related work in the W3C Web Security Context Working Group [WSC-XIT].
This specification uses the namespace prefix ds
to denote the XML Signature name space
http://www.w3.org/2000/09/xmldsig#
.
To sign an HTML document and its dependent content (e.g., stylesheets, scripting, images) according to this specification, separate hashes are computed over all these resources. The XML Signature specification [XMLDSIG] is used as a framework to encode the signature metadata and signature.
We use http://www.w3.org/2007/11/h6n/
as the HTML Signing metadata profile (cf section 7.4.4.3
Meta data profiles of [HTML401]).
To communicate that an external resource is a signature
resource as defined in this document, the HTML Signing
metadata profile is specified in the profile
attribute of the head
element. A
link
element is added to the document's
head
as follows. The href
attribute
of this link
element identifies the IRI reference
of the signature resource. This document defines two possible
profiles, which correspond to two different values of the
rel
attribute:
rel
attribute has the value
dsig-full
, then the signature resource is a
signature of the HTML document and its
dependent content, as described in 4.2 Full Profile.rel
attribute has the value
dsig-simple
, then the signature resource is a
signature of the HTML document only. No dependent content
is signed. The processing model in this case is described
in 4.1 Simple Profile.This section explains how to apply the framework specified in [XMLDSIG] to HTML documents on the Web. To do so, specific choices are made for various extension points within the XML Signature format. Validation semantics for signatures that might cover multiple representations of the same resource are defined.
The signature resource MUST consist of a single
ds:Signature
element. Canonical XML 1.0 [XMLC14N] MUST be used.
A later version of this specification may change the choice of canonicalization algorithm.
The signed document and dependent resources' representations are signed as octet streams; no XML processing (canonicalization or otherwise) is applied to the signed material.
In the simple profile, only the top-level HTML page is signed. No provisions for content-negotiation of the top-level resource are made in this profile; however, if multiple representations of the signed resource exist, they can in fact reference different signature resources.
If the simple profile is used, the
ds:SignedInfo
element MUST include a single
ds:Reference
element. The URI
attribute MUST reference the signed resource. The signed
resource is treated as an octet-stream, and not subject to
any further processing.
The ds:Reference
element MUST NOT have any
ds:Transform
descendants.
The ds:Signature
element MUST NOT have any
ds:Object
child elements.
In the full profile, the top-level document and its dependent resources are signed.
For HTML 4.01 [HTML401] and XHTML 1.0 [XHTML10] resources, the set of dependent resources is as follows:
src
and
usemap
attributes of the img
element;classid
,
data
, and usemap
attributes of the
object
element;src
and
usemap
attributes of the input
element;src
attribute
on the script
element;
Special processing applies to frames: The resources
referenced by the src
attribute on
frame
or iframe
elements SHOULD be
associated with separate signature resources using this full
profile. Implementation behavior for non-HTML resources is
UNDEFINED. We RECOMMEND that implementations ensure that
such dependent content be usefully signed, or otherwise
consider the signature invalid.
Further, the targets of link
elements with
the following link types are considered dependent resources:
Stylesheet
;transformation
, if the
http://www.w3.org/2003/g/data-view
metadata
profile [GRDDL] is used;If the full profile is used, one of the following two approaches MUST be used to sign dependent resources. For the parent document, the first approach MUST be used.
If only one representation of a given resource is
signed, a ds:Reference
element is used whose
URI
attribute identifies the signed resource
directly. In this case, XML Signature core validation
behavior applies, and ensures that the resource in question
will be hashed.
ds:Reference
element has
ds:DigestMethod
and ds:DigestValue
as its only child elements; no transforms are used.
If several representations of a given dependent resource
are signed, or if retrieval of a dependent resource is
deemed optional for proper rendering of the document by
the signer, then a ds:Reference
element is
used to identify a ds:Manifest
element by
way of a same-document URI reference. This
same-document URI reference MUST use a barename XPointer
[XPOINTER] to identify the manifest.
This ds:Reference
element's
Type
attribute MUST have the value
http://www.w3.org/2000/09/xmldsig#Manifest
.
The ds:Reference
element MUST include
precisely one ds:Transform
which MUST
identify the obligatory canonicalization algorithm under
this profile.
One ds:Manifest
element is used to collect
digest values for all known representations of one
resource. Therefore, each ds:Manifest
element is comprised of a collection of
ds:Reference
with identical
URI
attributes, but differring digest
values. No transforms or other XML processing are used.
Each ds:Manifest
element MUST be the only
child of a ds:Object
, which in turn MUST be
a direct child of the ds:Signature
element.
Note that the top-level ds:Reference
includes a same-document reference to the
ds:Manifest
element, not to its surrounding
ds:Object
.
The following is probably too strict. However, use of additional semantics might better be done by way of a specific profile, e.g., to support XADES.
In this profile, the ds:Object
element MUST
NOT be used for any other purpose but serving as a
container for one or more ds:Manifest
elements that are in turn referenced from
ds:Reference
children of
ds:SignedInfo
.
When the simple profile is used, applications MAY assume
that the only ds:Reference
element refers to
the signed resource without further verification. The
validity model is fully determined by XML Signature Core
Validation [XMLDSIG].
In the full profile, XML Signature core validation ensures
that all resources identified by ds:Reference
elements that are direct children of
ds:SignedInfo
have been retrieved, and that the
digest value obtained matches the
ds:DigestValue
included in the
ds:Reference
element. Core validation behavior
further ensures the integrity of all
ds:Manifest
elements.
The validity of a signature in the full model will be a
property of the subset of dependent resource representations
that is retrieved in order to render the main document.
Specifically, for every dependent resource's representation
that is retrieved, there MUST be at least one
ds:Reference
(either a direct child of
ds:SignedInfo
or embedded within a
ds:Manifest
) whose digest value matches the one
computed over the representation. The
ds:Reference
element's URI
attribute MUST identify the dependent resource.
Further, validators MUST verify that every dependent resource is referenced by the signature. It is an error for a signed document to have dependent resources that are not covered by the signature.
This specification does not mandate any particular methodology for comparing URI references. We RECOMMEND that signers use absolute URI references within both signed documents and signature resources which can be subject to a byte-by-byte comparison. While implementations MAY use sophisticated processing to perform URI-scheme sensitive comparisons, these are not required.
Key material MUST be embedded in the signature resource as a
sequence of X.509 v3 certificates [PKIX].
Each certificate is written as a
ds:X509Certificate
element. The certificates are
collected in a single ds:X509Data
element.
Certificate chains are validated according to Basic Path Validation [PKIX].
The ds:X509Date
element that is used to
communicate the key information MUST be the only child of
the ds:KeyInfo
element. There MUST be
precisely one ds:KeyInfo
element.
We expect this selection to change in a later version of this specification. Options include the choice of a single set of algorithms, or a mandate that algorithms corresponding to a common TLS algorithm suite be used. The latter choice would enable the same cryptographic and certificate infrastructure to support TLS and this signing mechanism.
Every signature computed under this profile MUST use a single hash algorithm for digest computation. Use of SHA-1 is RECOMMENDED.
Further, use of the RSA-SHA1 signature algorithm is RECOMMENDED. [XMLDSIG]
When signed resources are sent through HTTP, the
no-transform
directive SHOULD be set in the
Cache-Control
header of HTTP responses.
This specification assumes that the signer will control the availability of different representations of the same resource; therefore, the side effects of content negotiation are handled by permitting multiple digest values per resource.
An HTML document at http://www.example.com/
is
signed. There are no dependent resources.
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" > <head profile="http://www.w3.org/2007/11/h6n/"> <title>A Document</title> <link rel="dsig-simple" href="http://www.example.com/example1-sig.xml"/> </head> <body> <h1>This fine document</h1> <p>... claims to be signed.</p> </body> </html>
The signature according to the simple profile would look like this:
<?xml version="1.0" encoding="utf-8"?> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="http://www.example.com/"> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>94MeGM+p7kbbpEILvY/DHWLnqns=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>...</ds:SignatureValue> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> ... </ds:X509Certificate> <ds:X509Certificate> ... </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> </ds:Signature>
An HTML document at http://www.example.com/
is
signed. The document now uses a stylesheet that is deemed
optional by the signer, and it references a logo. The logo
is served as a GIF or PNG image, depending upon results from
content negotiation.
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"> <html xmlns="http://www.w3.org/1999/xhtml" > <head profile="http://www.w3.org/2007/11/h6n/"> <title>A Document</title> <link rel="dsig-full" href="http://www.example.com/example2-sig.xml"/> <link rel="stylesheet" href="http://www.w3.org/StyleSheets/base.css"/> </head> <body> <img src="http://www.w3.org/Icons/w3c_home" alt="W3C logo"/> <h1>This fine document</h1> <p>... is signed.</p> </body> </html>
In the signature, we notice that both the stylesheet and the logo have a manifest of their own.
<?xml version="1.0" encoding="utf-8"?> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> <ds:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/> <ds:Reference URI="http://www.example.com/"> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>omzq5ZXs3sFR+Rjwi15hhIDt7AM=</ds:DigestValue> </ds:Reference> <ds:Reference URI="#m1"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>DbYD6EWR95ZZITgTgNfhNcEFgZM=</ds:DigestValue> </ds:Reference> <ds:Reference URI="#m2"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>uhI+HSBS535v3LJiGWwLWIs7xzU=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue>...</ds:SignatureValue> <ds:KeyInfo> <ds:X509Data> <ds:X509Certificate> ... </ds:X509Certificate> <ds:X509Certificate> ... </ds:X509Certificate> </ds:X509Data> </ds:KeyInfo> <ds:Object> <ds:Manifest Id="m1"> <ds:Reference URI="http://www.w3.org/Icons/w3c_home"> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>+/MTaoTmyGkFLCGarzDR6xi2DZM=</ds:DigestValue> </ds:Reference> <ds:Reference URI="http://www.w3.org/Icons/w3c_home"> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>oI+ey2XCWx8gzw/8mCIbQf9+r08=</ds:DigestValue> </ds:Reference> </ds:Manifest> </ds:Object> <ds:Object> <ds:Manifest Id="m2"> <ds:Reference URI="http://www.w3.org/StyleSheets/base.css"> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <ds:DigestValue>Du57ThZlnWucVcntmHH5KCPFhz0=</ds:DigestValue> </ds:Reference> </ds:Manifest> </ds:Object> </ds:Signature>
This specification utilizes the HTML Signing metadata profile, and is signed with a public key that is contained in a self-signed X.509 certificate. The presence of a signature is indicated as follows:
<link rel="dsig-full" href="Overview-signature.xml" />
The signature can be verified by pointing the proof of concept implementation at this specification, or by running a generic XML Signature verification tool against the signature file.
This document started out as a hallway conversation between Thomas Roessler and Rigo Wenning. Valuable input and feed-back were provided by our colleagues Yves Lafon and Doug Schepers.