HTML Signing Profile

4.1 Simple Profile

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.

4.2 Full Profile

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:

• resources referenced by the src and usemap attributes of the img element;
• resources referenced by the classid, data, and usemap attributes of the object element;
• resources referenced by the src and usemap attributes of the input element;
• resources refercened by the 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.

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

   As in the simple profile, this ds:Reference element has ds:DigestMethod and ds:DigestValue as its only child elements; no transforms are used.

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

4.3 Signature Validity Model

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.

4.4 Signature Key Information

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.

4.5 Selection of cryptographic algorithms

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]

6.1 Simple signing example

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>

6.2 Full signing example

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>

6.3 This Document

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.