IETF Logo W3C Logo

XML-Signature Data Model Design

WG Draft 1999-August-23

This Working Group version:
http://www.w3.org/Signature/Drafts/xml-dsig-datamodel-990823.html [ASCII]
Previous version:
...
Editor
Joseph Reagle Jr. <reagle@w3.org>
Author(s):
Joseph Reagle Jr. <reagle@w3.org>
Ralph Swick <swick@w3.org>

Copyright  1999 The Internet Society & W3C (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

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.


Abstract

This document addresses the data model and semantics with respect to the things signatures sign.

Introduction

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.

Graphical Representation

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

 xmldsig-datamodel-19990819-comments.gif (31947 bytes)

XML/RDF-abbreviated Syntax

Objects and References

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

Manifest of External References

This example includes a  manifest for external XML objects. The data model of the instance looks like:

xmldsig-datamodel-19990819-i1.gif (23768 bytes)

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. 

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

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.

Signing the Native Encoding of a Package Document

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>