Copyright © 1999 The Internet Society & W3C (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This is a WG XML Signature Design draft. It is likely that this document will not be published as a TR or ietf-draft, but will be used as the basis of some other document.
Please send comments to the editor <reagle@w3.org> and cc: the list <w3c-ietf-xmldsig@w3.org>. Publication as a Working Draft does not imply endorsement by the W3C membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite W3C Drafts as other than "work in progress".A list of current W3C working drafts can be found at http://www.w3.org/TR. Publication as a Working Draft does not imply endorsement by the W3C membership.
This document addresses the data model and semantics with respect to the things signatures sign.
The following is a DLG representation of the signature data model -- done in visio.While it looks complex on first glance, it is fairly simple and solves addresses many rat holes quite well I think. Also, remember a useful way to read these things are:
"Subject (has/is) Predicate Object" or
"Resource is related to Value via Property"
like:
Signature is Over Manifest. or
Reference is related to hash-value via digest
For background on the nature of the assertions/relationship of HTTP GET:
"external" and "show(M,C,I)" see State and Storage: Files, Documents, and
Resources. For my first muddled attempt at tweaking out the meaning of the assertions
in a package, manifest, and trusted-cache, see Referents
and Resources.
I will define all these relationships more formally soon.
The following is a graphical representation with comments of the data model of a signature over two core signature applications: manifest and package.
<reference> and <object> take content.inline and content.EB and yield *.result. This production occurs based on the parameters of the operations (hash, c14n, encoding, etc.). This intermediate results are not represented in the syntax explicitly. However, we do need a feature for distinguishing between signing the actual <object> (the encoded form) and content.inline.result (the decoded (processed) form.). See the section on signing the native encoding of a packaged document.
This example includes a manifest for external XML objects. The data model of the instance looks like:
It specifies the encoding algorithm of the resource, as well as the operations of XSLT and c14n to the Web resource specified by the xlink:href. The manifest is than c14n'ized and signed according to the property+values of the SignedInfo node.
A manifest is a very minimalistic trust application that includes a number of trusted assertions that all should be confirmed for the trusted-manifest semantic to evaluate to true. In this case, there are three constituent assertions: (1) the signature over the manifest validates, (2) that the first resource when processed yields the stated digest value, and (3) that the second resource when processed yields the stated digest value.
<Signature xmlsn:dsig="http://w3.org/Signature"
id="foo">
<C14nAlg value="http://www.w3.org/1999/08/xmldsig-ns/c14n/">
<SigAlg value="http://www.w3.org/1999/08/xmldsig-ns/SigAlg/">
<Over>
<Manifest>
<Reference>
<Encoding value="http://..."/>
<XSLT value="http://..."/>
<C14n value="htatp://..."/>
<DigestAlg value="http://..."/>
<Resource xmlns:xlink="http://www.w3.org/XML/XLink/0.9"
xlink:type="simple"
xlink:href="http://web.mit.edu/index.html"/>
<digest>a23bcd45</digest>
</Reference>
<Reference>
<Encoding value="http://..."/>
<XSLT value="http://..."/>
<C14n value="http://..."/>
<DigestAlg value="http://..."/>
<Resource xmlns:xlink="http://www.w3.org/XML/XLink/0.9"
xlink:type="simple"
xlink:href="http://w3.org/People/Reagle"/>
<digest>54dcbab123</digest>
</Reference>
</Manifest>
<Over>
<SigValue>54lkasdf234</SigValue>
<KeyInfo>
<KeyID>3</KeyID>
<KeyInfo>
</Signature>
Recall (by the data model) that the manifest may also include actual in-line objects. Those assertions are "ANDed" as well.
This example includes a package that includes a reference and an object. ( It can
include (package* | manifest*)+ ) The meaning of the package node in the data model
is the same as the manifest (all objects are references ANDed) plus
the additional assertion that all objects and references within the package are related to
each other through identity.
<Signature xmlsn:dsig="http://w3.org/Signature"
id="foo2">
<C14nAlg value="http://www.w3.org/1999/08/xmldsig-ns/c14n/">
<SigAlg value="http://www.w3.org/1999/08/xmldsig-ns/SigAlg/">
<Over>
<Package>
<Reference>
<Encoding value="http://..."/>
<XSLT value="http://..."/>
<C14n value="http://..."/>
<DigestAlg value="http://..."/>
<Resource xmlns:xlink="http://www.w3.org/XML/XLink/0.9"
xlink:type="simple"
xlink:href="http://web.mit.edu/index.html"/>
<digest>54dcbab123</digest>
</Reference>
<Object>
<Encoding value="http://..."/>
<XSLT value="http://..."/>
<C14n value="http://..."/>
<DigestAlg value="http://..."/>
<Inline>74a4lka34lkj</Inline>
<digest>54dcbab123</digest> ; same value as first digest
</Object>
</Package>
</Over>
<SigValue>54lkasdf234</SigValue>
<KeyInfo>
<KeyID>3</KeyID>
<KeyInfo>
</Signature>
Frequently people will receive signed statements and place them into the database trust engine as true. However, people also wish to derive trust values for values that are unknown. One such application is that of a trusted-cache. Using the same format as that of the package, one may wish to derive a trust value for the assertion that dereferencing the reference will show the same content as that in the object. In this case, one would evaluate the reputation of the key, the evaluation of Object's digest, and the signature validity over the package to derive an acceptable trust value of the cache assertion.
In another case, the reputation of the key might be the unknown variable, and I will use the evaluation of the identity of the reference with the object (that is confirmed on-line) to derive a trust value associated with the key. In fact, I might process numerable such packages to derive a reputation for that key as a trusted-cache service.
Frequently people would like to transmit documents they've signed. Furthermore, they
would like to include an encoded form of that document with the signature, but have the
signature apply to the native encoding, not the packaged encoding. Since the package
element definition includes identity between references and objects, this functionality
can easily be provided. One would use the <object>to include the encoded
form, and then reference that form from a reference within a <Package>.
<Signature xmlsn:dsig="http://w3.org/Signature"
id="foo3">
<C14nAlg value="http://www.w3.org/1999/08/xmldsig-ns/c14n/">
<SigAlg value="http://www.w3.org/1999/08/xmldsig-ns/SigAlg/">
<Over>
<Package>
<Object id="my_file">
<Encoding value="http://..."/>
<Inline>74a4lka34lkj</Inline>
</Object>
<Reference>
<Encoding value="http://..."/>
<DigestAlg value="http://..."/>
<Resource xmlns:xlink="http://www.w3.org/XML/XLink/0.9"
xlink:type="simple"
xlink:href="#my_file"/>
<digest>54dcbab123</digest>
</Reference>
</Package>
</Over>
<SigValue>54lkasdf234</SigValue>
<KeyInfo>
<KeyID>3</KeyID>
<KeyInfo>
</Signature>