Referents and Resources: XMLSignature Data Model Design

W3C Status of this Document

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.

Introduction

The following is a DLG representation of a single instance/example of a data model. It isn't redundant, but could easily be used to show multiple signature over a single manifest or package, etc. 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:

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.

Graphical Representation

The following is a graphical representation with comments of the data model of a signature over two applications: manifest and package.

XML/RDF-abbreviated Syntax

Manifest of External References

This example includes a manifest for external XML objects. 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/">

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

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

Package of Inline Objects

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 plus the additional assertion that all objects or 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/">
<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>
<SigValue>54lkasdf234</SigValue>
<KeyInfo>
   <KeyID>3</KeyID>
<KeyInfo>
</Signature>

Trusted Caching

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.

XML-Signature Data Model Design

WG Draft 1999-August-21