This document specifies a P3P Assurance Signature Profile: the intended meaning
(assures) of the key holder is bound to the signature via a
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
for further exploration/discussion.
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:
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.
The design philosophy and requirements of this specification are to:
Signatureis 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:
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.
<SignatureProperty Id="Assurance1" Target="#Signature1"
The following abbreviated Signature signs the P3P-Policy, and signs (and is semantically bound to) the assurance itself.
<KeyInfo>KeyInfo of the Disputes Service</KeyInfo>
<SignatureProperty Id="Assurance1" Target="#Signature1"
The following abbreviated example describes the policy being assured, and uses the
attribute to reference the signature.
The assurance semantic is:
DISPUTE serviceasserts that the P3P policy is accurate and that the P3P
DISPUTE servicecommits to the enumerated
REMEDIES. Verification of this semantic requires (1) signature validation where (2) the signature key holder and P3P
DISPUTE serviceare 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/' version='0.1' xmlns='http://www.w3.org/2000/10/XMLSchema' xmlns:profile='http://www.w3.org/2000/12/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
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
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
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
Reference's to the
SignatureProperty is identified to be of
A time-stamp appearing in a
SignatureProperty and identified as such via
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
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
"... the signing application should be very careful about what it signs (it should
understand what is in the
Extended Example (
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
[i1] <SignatureProperty Id="Property-Assurance" Target="#Signature1"
[i3] <profile:Assures profile:Policy="http://www.example.org/p3p.xml"
[i4] xmlns:profile="http://www.w3.org/2000/12/xmldsig-p3p-profile/" />
An [RDF] reification of this statement is:
[r1] <SignatureProperty Id="Property-Assurance" Target="#Signature1"
[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"/>
Note that this specification (the P3P Assurance Signature Profile):
<Assures>from the profile namespace [
i3] maps to
The signature specification:
&dsig;SignaturePropertiesto mean its content is about the signature;
i1] that acts as the
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 "
are made. One could also rely upon a natural language statement within the (unfortunately
ambiguous) context of HTML's
[a1] <SignatureProperty Id="Property-Assurance" Target="#Signature1"
[a3] <p xmlns:html="http://www.w3.org/1999/xhtml">I agree
with everything signed</p>
A P3P Signature Profile signature is a valid signature [XMLDSIG] with the following REQUIRED constraints.
CanonicalizationMethodis Canonical XML:
SignatureMethods are DSA or RSA.
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,
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.
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.
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