A P3P Assurance Signature Profile

Draft 19-December-2000

This version:
Latest version:
Previous version:
Joseph Reagle <reagle@w3.org>
See Acknowledgements


This document specifies a P3P Assurance Signature Profile: the intended meaning (assures) of the key holder is bound to the signature via a SignatureProperty.

Status of this document

This document has no status what-so-ever. It is a very rough draft of the author that hasn't received substantive review. It is not intended to be a normative specification. Instead, it an captures the authors' thoughts on how applications might use the XML Signature specification to meet their requirements (defining signature semantics and algorithm profile); the example application is P3P. There is/was no Working Group consensus on the use of SignatureProperty as specified in this document; instead this document presents this as a possible/permitted use of SignatureProperty for further exploration/discussion.

Table of Contents

  1. Introduction
    1. Editorial Conventions
    2. Design Philosophy
    3. Versions, Namespaces and Identifiers
    4. Acknowledgements
  2. Overview and Examples
    1. Assurance Overview
    2. XML Signature Overview
    3. p3p.xml Overview
  3. P3P Assurance
    1. Signature Semantics
  4. XML Signature Profile
  5. P3P Policy
  6. Schema, Transforms, and Examples
  7. References
  8. Authors' Address

1.0 Introduction

This document specifies a P3P [P3P] Assurance Signature [XMLDSIG] Profile. Perhaps the best introduction to this specification is found within the introduction of its predecessors:

The Platform for Privacy Preferences Project (P3P) enables Web sites to express their privacy practices in a standard format that can be retrieved automatically and interpreted easily by user agents. P3P user agents will allow users to be informed of site practices (in both machine- and human-readable formats) and to automate decision-making based on these practices when appropriate. Thus users need not read the privacy policies at every site they visit.... It provides a way for a Web site to encode its data-collection and data-use practices in a machine-readable XML format known as a P3P policy.

(The excerpt from XML Signature also motivates why a XML Signature profile is necessary.)

XML Signature is a method of associating a key with referenced data (octets); it does not normatively specify how keys are associated with persons or institutions, nor the meaning of the data being referenced and signed. Consequently, while this specification is an important component of secure XML applications, it itself is not sufficient to address all application security/trust concerns, particularly with respect to using signed XML (or other data formats) as a basis of human-to-human communication and agreement. Such an application must specify additional key, algorithm, processing and rendering requirements.

The purpose of this specification if to specify the following:

[def:] P3P Assurance Signature Profile
(1) a definition of the assured semantic under its namespace and (2) a profile of XML Signature (constraints over algorithms, transforms, key types, etc.) in a P3P application context.

1.1 Editorial and Conformance Conventions

For readability and brevity this document uses the term "signature(s)" to refer to XML Signatures and the application context is always presumed to be P3P. An understanding of [XMLDSIG] is necessary to understand this specification; understanding of [P3P] is optional though it contributes to this document's motivation.

This specification uses XML Schemas [XML-schema].

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in RFC2119 [KEYWORDS]:

"they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)"

Consequently, capitalized keywords are used to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. These key words are not used (capitalized) to describe XML grammar; schema definitions unambiguously describe such requirements and we wish to reserve the prominence of these terms for the natural language descriptions of protocols and features.

1.2 Design Philosophy

The design philosophy and requirements of this specification are to:

  1. Define what it means for a P3P Policy to be assured via an XML Signature.
  2. Provide detached signatures for P3P Policies and Assurances.
    1. Enveloping signatures MAY contain the P3P Policy Reference. This can be convenient in that all the files are included together, but this has the following two disadvantages: the Signature is the root element, and XPointer is required to select portions of the document.
    2. Enveloped signatures are prohibited by P3P's content model.
  3. Be concise and unambiguous.

The following issues still need to be addressed:

  1. P3P: It would be nice if the signature could be included within a P3P policy.
  2. P3P: Should this address the P3P Policy Reference File as well?
  3. DSIG: should the SignatureProperties type be SignatureProperty?

1.3 Versions, Namespaces and Identifiers

The XML namespace [XML-ns] URI that MUST be used by implementations of this (dated) specification is:


1.4  Acknowledgements

The comments of the following are gratefully acknowledged though any mistakes and daft ideas are solely my own and inclusion does not necessarily mean agreement or consensus:

2.0 Overview and Examples

This section provides an overview of a P3P Assurance Signature Profile, an XML Signature, and a P3P-Policy.

2.1 Assurance Overview

The following is an XML instance of a P3P Assurance semantic of a signature over a P3P-Policy. The assurances uses the RDF data-model to state that: A SignatureProperty assures a P3P Policy.


<SignatureProperty Id="Assurance1" Target="#Signature1"
  <Assures Policy="http://www.example.org/p3p.xml"

2.2 XML Signature Overview

The following abbreviated Signature signs the P3P-Policy, and signs (and is semantically bound to) the assurance itself.


<Signature Id="Signature1" xmlns="http://www.w3.org/2000/09/xmldsig#">
    <Reference URI="http://www.example.org/p3p.xml">
        <Transform Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000907"/>
     <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
    <Reference URI="#Assurance1"
     <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
   <KeyInfo>KeyInfo of the Disputes Service</KeyInfo>
        <SignatureProperty Id="Assurance1" Target="#Signature1"
           <Assures Policy="http://www.example.org/p3p.xml"

2.2 P3P-Policy Overview

The following abbreviated example describes the policy being assured, and uses the p3p:verification attribute to reference the signature.


<POLICY xmlns="http://www.w3.org/2000/09/15/P3Pv1"
  <DISPUTES resolution-type="independent"
   <IMG src="http://www.PrivacySeal.example.org/Logo.gif"
        alt="PrivacySeal's logo"/>
   <DATA ref="#dynamic.clickstream.clientip"/>
   <DATA ref="#dynamic.http.useragent"/>

3.0 P3P Assurance

The assurance semantic is:

[def:] Assured
the P3P DISPUTE service asserts that the P3P policy is accurate and that the P3P DISPUTE service commits to the enumerated REMEDIES. Verification of this semantic requires (1) signature validation where (2) the signature key holder and P3P DISPUTE service are the same.

The assurance content model permits the P3P Policy and XML Signature to be referenced as external files, or as internal content.

Schema Definition:

<?xml version='1.0'?> 
<!DOCTYPE schema 
  SYSTEM 'http://www.w3.org/1999/XMLSchema.dtd' 

<schema targetNamespace='http://www.w3.org/2000/12/xmldsig-p3p-profile/' 

   <element name='Assured'> 
         <element ref='profile:P3P-Policy' minOccurs='0' />
         <element ref='profile:Signature' minOccurs='0' />
       <attribute name='via' type='URI'/> 
       <attribute name='Id' type='ID' use='optional'/> 

   <element name='P3P-Policy'> 
         <any namespace='http://www.w3.org/2000/10/18/P3Pv1'/>
       <attribute name='Id' type='ID' use='required'/> 

   <element name='Signature'> 
         <any namespace='http://www.w3.org/2000/09/xmldsig#'/>
       <attribute name='Id' type='ID' use='required'/> 


3.1 Signature Semantics

[XMLDSIG] specifies a way of providing (primarily) data object integrity by applying his key to the data object via cryptographic algorithms. The fact that one signs the characters, "I saw a UFO" does not mean the signature creator (key-holder) actually saw a UFO or even believes he did; maybe someone else spoke of seeing a UFO and the key-holder is merely acting as a notary and wants to secure the statement in the public record. The question then is how does one actually say such a thing? How does one bind a semantic (e.g., assert, believe, vouch, notarize, etc.) to the signature? How does one distinguish between signing some document that might be a statement  (e.g., "The sky is blue.") or even a statement about a statement (e.g., "He said, 'the sky is blue.'") and actually saying it?

In many cases, the meaning of a signature is inferred from its context. For instance, a payment application might define, as part of its specification, that if a Signature appears within an authorization element of a payment voucher, it means the author/key-holder is authorizing the payment. In another context, a key-holder may have one or more keys with an associated semantic. For example, one key is used for assertions I make, another key is used for notarized time-stamping; or as one can indicate in [RFC2459]'s KeyUsage field, one key is used for non-repudiation and another for certificate signing. However, these techniques rely upon the external (from the signature) specification, or implicit context of the application. Consequently these semantics are lost outside of their context; if they are not well specified they may not even be shared by different users of the same application -- with a likely result of legal action!

Fortunately, [XMLDSIG] provides a mechanism of making a distinction between the simple bits being signed, and information related to the actual signature creation; this permits one to step outside the circle of lending integrity to bits and explicitly "bootstrap" meaning. The SignatureProperty element provides a mechanism by which "Additional information items concerning the generation of the signature(s) can be placed..."; I use this to include the intent/meaning of the signature generation. This "bootstrapping" happens when the Reference's to the SignatureProperty is identified to be of Type="&dsig;SignatureProperties".

A time-stamp appearing in a SignatureProperty and identified as such via Type is not just any old time-stamp that has integrity, but a time-stamp for that signature. When a signature semantic (such as "I vouch") is included and signed in a SignatureProperty (and identified as such) it is more than some characters with integrity, it's an expression of the key holder about the signature. This means that while some signature applications are willing to sign data without  "understanding it" (e.g., a simple time-stamping service) when it comes to SignatureProperty, "... the signing application should be very careful about what it signs (it should understand what is in the SignatureProperty)" [XMLDSIG: 2.2 Extended Example (Object and SignatureProperty)]

Consequently, this specification permits a signature semantic to be expressed with the natural language semantic defined is section 3.0 using the following XML syntax as part of a SignatureProperty:

[i0] <SignatureProperties>
[i1]   <SignatureProperty Id="Property-Assurance" Target="#Signature1"
[i2]    xmlns="http://www.w3.org/2000/09/xmldsig#">
[i3]     <profile:Assures profile:Policy="http://www.example.org/p3p.xml"
[i4]       xmlns:profile="http://www.w3.org/2000/12/xmldsig-p3p-profile/" />
[i5]   </SignatureProperty>
[i6] </SignatureProperties>

An [RDF] reification of this statement is:

[r0] <SignatureProperties>
[r1]   <SignatureProperty Id="Property-Assurance" Target="#Signature1"
[r2]        xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#""
[r3]        xmlns:profile="http://www.w3.org/2000/12/xmldsig-p3p-profile/"/>
[r4]        <rdf:type rdf:resource="rdf:Statement"/>
[r5]        <rdf:subject rdf:resource="#Signature1"/>
[r6]        <rdf:type rdf:resource="profile:Assures"/>
[r7]        <rdf:object rdf:resource="http://www.example.org/p3p.xml"/>
[r8]   </SignatureProperty>
[r9] <SignatureProperties>

Note that this specification (the P3P Assurance Signature Profile):

  1. defines the meaning of  <Assures> from the profile namespace [i4];
  2. declares that it is a statement in the RDF data model [r4];
  3. specifies that [i3]  maps to rdf:type [r6] and rdf:object [r7].

The signature specification:

  1. defines SignatureProperty and the Reference Type of &dsig;SignatureProperties to mean its content is about the signature;
  2. provides the Target attribute  [i1] that acts as the rdf:subject [r4] of the reified statement.

Finally, while this specification chose to model its semantic in the [RDF] data model, not all signature semantics need follow suit. We choose to do so because it results in cleaner design and offers the possibility of agents being able to make inferences if more formal definitions of "profile:assures" are made. One could also rely upon a natural language statement within the (unfortunately ambiguous) context of HTML's p element.

[a0] <SignatureProperties>
[a1]   <SignatureProperty Id="Property-Assurance" Target="#Signature1"
[a2]    xmlns="http://www.w3.org/2000/09/xmldsig#">
[a3]     <p xmlns:html="http://www.w3.org/1999/xhtml">I agree
         with everything signed</p>
[a5]   </SignatureProperty>
[a6] <SignatureProperties>

4.0 XML Signature Profile

A P3P Signature Profile signature is a valid signature [XMLDSIG] with the following REQUIRED constraints.

  1. The permissible CanonicalizationMethod is Canonical XML:
  2. The permissible SignatureMethods are DSA or RSA.
  3. The permissible DigestMethod   is SHA-1
  4. The permissible Transforms are:
    1. Canonical XML:
    2. P3P Statement to HTML/English XSLT: This specification provides a [XSLT] instance that transforms a P3P statement into an HTML page that uses English to describe that statement.
  5. The permissible KeyInfo
    1. DSAKeyValue or RSAKeyValue

Note, for purposes of further demonstration I considered refining this profile to actually meet the requirements of the "advanced electronic signature" as specified by the European Directive 1999/93/EC. This would require the use of X509Data, an extension designating it was a "qualified certificate", and as part of the signature, dsig:References over (1) the assurer's signature policy and (2) a timestamp. Given that I wish to focus on the P3P application context and signature semantics in this document, I will forgo that exercise for the time being.

5.0 P3P Policy

The P3P Disputes verification attribute should be the URI of the assuring signature. No additional constraints or specification are made over [P3P], nor are any additional semantics introduced via this specification's namespace.

6.0 Schema, Transforms and Examples

XSLT P3P Statement to HTML Transform
This specification provides a [XSLT] instance that transforms a P3P statement into an HTML page that uses English to describe that statement.
P3P Assurance Signature Profile Schema

7.0 References

RFC2119 Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. March 1997.
The Platform for Privacy Preferences 1.0 (P3P1.0) Specification. W3C Working Draft. Cranor, Langheinrich, Marchiori, Presler-Marshall, and Reagle, October 2000.
Resource Description Framework (RDF) Model and Syntax Specification. W3C Recommendation. Lassila and Swick. Febuary 1999.
Internet X.509 Public Key Infrastructure Certificate and CRL Profile. R. Housley, W. Ford, W. Polk, D. Solo. January 1999.
XML-Signature Syntax and Processing. W3C Working Draft. Eastlake, Reagle, and Solo. September 2000.
Canonical XML. Working Draft. J. Boyer. September 2000.
Namespaces in XML Recommendation. T. Bray, D. Hollander, A. Layman. January 1999.
XML Schema Part 1: Structures Working Draft. D. Beech, M. Maloney, N. Mendelshohn. September 2000.
XML Schema Part 2: Datatypes Working Draft. P. Biron, A. Malhotra. September 2000.
XSL Transforms (XSLT) Version 1.0. Recommendation. J. Clark. November 1999.

8. Authors' Address

Joseph M. Reagle Jr., W3C
Massachusetts Institute of Technology
Laboratory for Computer Science
NE43-350, 545 Technology Square
Cambridge, MA 02139
Phone: + 1.617.258.7621
Email: reagle@w3.org