Copyright © 2001 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document specifies a P3P Assurance Signature Profile: the
intended meaning (assures) of the key holder is bound to the
signature via a SignatureProperty.
This Note is available for W3C-member review. It is not intended
to be a normative specification. Instead, it 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.
This is not a product or deliverable of any Working Group, nor does
it reflect a consensus on how to use XML Signature's
SignatureProperty. Instead this document presents a possible
use of SignatureProperty, as permitted (but not
required) by the XML Signature specification, for further
exploration/discussion.
No commitment is made to update this Note. However, if you have comments, please send them to the <reagle@w3.org>
A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR.
This document specifies a P3P [P3P] Assurance Signature [XMLDSIG] Profile. Perhaps the best introduction to this assurance profile 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.
Consequently, the purpose of this document is to specify the following:
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 design philosophy and requirements of this specification are to:
Signature is the root element, and XPointer is
required to select portions of the document.The following issues still need to be addressed:
The XML namespace [XML-ns] URI that MUST be used by implementations of this (dated) specification is:
xmlns="http://www.w3.org/2001/02/xmldsig-p3p-profile"
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:
This section provides an overview of a P3P Assurance Signature Profile, an XML Signature, and a P3P-Policy.
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.
#Assurance1
<SignatureProperty Id="Assurance1" Target="#Signature1"
xmlns="http://www.w3.org/2000/09/xmldsig#">
<Assures
Policy="http://www.example.org/p3p.xml"
xmlns="http://www.w3.org/2000/10/xmldsig-p3p-profile/"/>
</SignatureProperty>
The following abbreviated Signature signs the P3P-Policy, and signs (and is semantically bound to) the assurance itself.
http://www.example.org/Signature.xml
<Signature Id="Signature1"
xmlns="http://www.w3.org/2000/09/xmldsig#">
<SignedInfo>
<CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000907"/>
<SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"/>
<Reference URI="http://www.example.org/p3p.xml">
<Transforms>
<Transform
Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000907"/>
</Transforms>
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
</Reference>
<Reference URI="#Assurance1"
Type="http://www.w3.org/2000/09/xmldsig#SignatureProperties">
<DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>1234x3rvEPO0vKtMup4NbeVu8nk=</DigestValue>
</Reference>
</SignedInfo>
<SignatureValue>MC0CFFrVLtRlk=...</SignatureValue>
<KeyInfo>KeyInfo of the Disputes
Service</KeyInfo>
<Object>
</SignatureProperties>
<SignatureProperty Id="Assurance1"
Target="#Signature1"
xmlns="http://www.w3.org/2000/09/xmldsig#">
<Assures
Policy="http://www.example.org/p3p.xml"
xmlns="http://www.w3.org/2001/02/xmldsig-p3p-profile"/>
</SignatureProperty>
</SignatureProperties>
</Object>
</Signature>
The following abbreviated example describes the policy being
assured, and uses the p3p:verification attribute to
reference the signature.
http://www.example.org/p3p.xml
<POLICY
xmlns="http://www.w3.org/2000/09/15/P3Pv1"
discuri="http://www.example.com/PrivacyPracticeBrowsing.html">
...
<DISPUTES-GROUP>
<DISPUTES resolution-type="independent"
service="http://www.PrivacySeal.example.org"
short-description="PrivacySeal.example.org"
verification="http://www.example.org/Signature.xml">
<IMG
src="http://www.PrivacySeal.example.org/Logo.gif"
alt="PrivacySeal's
logo"/>
<REMEDIES><correct/></REMEDIES>
</DISPUTES>
</DISPUTES-GROUP>
<STATEMENT>
<PURPOSE><admin/><develop/></PURPOSE>
<RECIPIENT><ours/></RECIPIENT>
<RETENTION><stated-purpose/></RETENTION>
<DATA-GROUP>
<DATA
ref="#dynamic.clickstream.clientip"/>
<DATA ref="#dynamic.http.useragent"/>
</DATA-GROUP>
</STATEMENT>
</POLICY>
The assurance semantic is:
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/2001/02/xmldsig-p3p-profile'
version='0.1'
xmlns='http://www.w3.org/2000/10/XMLSchema'
xmlns:profile='http://www.w3.org/2001/02/xmldsig-p3p-profile'
elementFormDefault='qualified'>
<element name='Assured'>
<complexType>
<all>
<element ref='profile:P3P-Policy' minOccurs='0' />
<element ref='profile:Signature' minOccurs='0' />
</all>
<attribute name='via' type='URI'/>
<attribute name='Id' type='ID' use='optional'/>
</complexType>
</element>
<element name='P3P-Policy'>
<complexType>
<sequence>
<any namespace='http://www.w3.org/2000/10/18/P3Pv1'/>
</sequence>
<attribute name='Id' type='ID' use='required'/>
</complexType>
</element>
<element name='Signature'>
<complexType>
<sequence>
<any namespace='http://www.w3.org/2000/09/xmldsig#'/>
</sequence>
<attribute name='Id' type='ID' use='required'/>
</complexType>
</element>
</schema>
[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/2001/02/xmldsig-p3p-profile"
/>
[i5] </SignatureProperty>
[i6] </SignatureProperties>
Which means the same as the following [RDF]:
[r0] <rdf:Description
ID="Property-Assurance" about="#Signature1"
[r1]
xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
[r2] <profile:Assures
resource="http://www.example.org/p3p.xml"
[r3]
xmlns:profile="http://www.w3.org/2000/12/xmldsig-p3p-profile"
/>
[r4] </rdfDescription>
The reification of this statement (breaking it down into its "grammatical" data model) is
[rA] <rdf:type
resource="rdf:Statement"/>
[rB] <rdf:subject resource="#Signature1"/>
[rC] <rdf:predicate resource="profile:Assures"/>
[rD] <rdf:object
resource="http://www.example.org/p3p.xml"/>
While this specification chose to model its semantic in the [RDF] data model, not all signature semantics
need follow suit. I 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 might also see
instances of natural language statements within the (unfortunately
ambiguous) context of HTML's p element.
[n0] <SignatureProperties>
[n1] <SignatureProperty Id="Property-Assurance"
Target="#Signature1"
[n2]
xmlns="http://www.w3.org/2000/09/xmldsig#">
[n3] <p
xmlns:html="http://www.w3.org/1999/xhtml">I agree
with everything
signed</p>
[n5] </SignatureProperty>
[n6] <SignatureProperties>
A P3P Signature Profile signature is a valid signature [XMLDSIG] with the following REQUIRED constraints.
CanonicalizationMethod is Canonical XML:
SignatureMethods are DSA or
RSA.DigestMethod is SHA-1
Transforms are:
DSAKeyValue or RSAKeyValue
http://www.w3.org/2000/09/xmldsig#dsa-sha1Note, 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.
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.