XML Signature

Joseph M. Reagle Jr.
<reagle@w3.org>

IETF/W3C XML Signatures Co-Chair
W3C/LCS/MIT

Agenda

Working Group Background
Design Principles/Goals
Technical Design and Open Issues
The Near Future

This presentation is merely one WG member's view/interpretation of the work with a bias of my expectation/hope for future direction.

Background

IETF BOF and W3C Signed XML Workshop in March and April
WG chartered, IETF meeting in Oslo in July.
W3C/IETF had numerous submission/proposals on XML signatures (particularly from the forms domain.)
Present specification evolved from very simple proposal made in August.
Requirements document completed W3C Last Call, now working its way through the IESG towards Information RFC.
Three drafts of the core syntax and processing

Design Principles/Goal

The specification must describe how to use XML syntax to represent a signature over digital content (and XML content in particular).
XML-signatures are generated from a hash over a list of references and the digest value of the references' content.
The meaning of a signature is simple: The XML-signature syntax associates the content of resources listed with a key via a strong one-way transformation.

No explicit/documented requirement for location independent signatures, but has been a feature of most proposals and the WG agreess it is a useful thing.

Present Design Overview

<Signature>
<SignedInfo>
    (CanonicalizationMethod)
    (SignatureMethod)
    (ObjectReference)+
</SignedInfo>
(SignatureValue)
(KeyInfo)?
(Object)*
</Signature>

SignedInfo is the content that is signed.
ObjectReferences identify the resources that the have content being signed (via a DigestValue)
Other KeyInfo and Objects may be included within the Signature element.

"Signature Validation"

Must be clear by what we mean when a signature is "valid"

Signature Validation: Does the SignatureValue matches the result of processing SignedInfo with CanonicalizationMethod and SignatureMethod as specified in §6.2? (Did SignedInfo or key change?)
Reference Validation: Does the DigestValue of the derferenced URI matches the DigetsValue in SignedInfo? (Did the content referenced from SignedInfo change.)
Trust/Application Validation: Does the application trust the signed assertions? (Was the key strong enough, is it from a trusted party, was it signed by a non-buggy application?)

Present Design Example

<Signature ID="5"
           xmlns="http://www.w3.org/1999/10/signature-core">
<SignedInfo> ; scope of sig processing
    <CanonicalizationMethod ; for SignedInfo
      Algorithm="http://www.w3.org/1999/xmldsig-core/c14n"/>
    <SignatureMethod Algorithm="dsig:dsaWithSHA-1"/>
    <ObjectReference URI="www.mypage.com" ; points to resource
      <DigestMethod Algorithm="http://...sha1"/>
      <DigestValue>a53uud43</DigestValue>
    </ObjectReference>
    <ObjectReference IDREF="#timestamp" ; points to resource
      Type="http://www.w3.org/1999/sig1/signatureattributes">
      <Transforms> ; source tree to output octect
        <Tranform name="http://www.w3.org/1999/xmldsig-core/c14n"/>
      </Transforms>
      <DigestMethod Algorithm="http://...sha1"/>
      <DigestValue>a53uud43</DigestValue>
    </ObjectReference>
</SignedInfo>
<Object ID="timestamp">
    <timestamp about="#5"
         xmlns="http://www.ietf.org/rfc/1234">
      <date>19990908</date>
      <time>14:34:34:34</time>
    </timestamp>
</Object>
<SignatureValue
   encoding="urn:ietf-org:base64">dd2323dd</SignatureValue>
<KeyInfo> ; not necessarily signed!
     <keyname>Solo</keyname>
</KeyInfo>
</Signature>

SignedInfo

<SignedInfo> ; scope of sig processing
    <CanonicalizationMethod ; for SignedInfo
      Algorithm="http://www.w3.org/.../xml-c14n"/>
    <SignatureMethod Algorithm="dsig:dsaWithSHA-1"/>
    <ObjectReference URI="http://www.myhome.com" ; points to object
     ...
    </ObjectReference>
    <ObjectReference IDREF="#timestamp" ; points to object
     ...
    </ObjectReference>
</SignedInfo>

SignedInfo does not necessarily include KeyInfo nor an explicit SignatureAttributes element. Instead, use an additional ObjectReference to an Object that includes these semantics.
Canonicalization is contentious with respect to SignedInfo. Presently, no mandatory to use, perhaps a simple mandatory to implement.
Entropy: XML is redundant with lots of static text, Canonical XML (with namespaces expanded) is even more so.

ObjectReference

<ObjectReference IDREF="#timestamp" ; points to object
Type="http://www.w3.org/1999/xmldsig-core/SignatureAttributes">
<Transforms> ; source tree to output octect
     <Transform Algorithm="http://w3.org/1999/XPath"/>
     <Transform Algorithm="http://w3.org/1999/xmldsig-core/c14n"/>
   </Transforms>
<DigestMethod Algorithm="http://w3.org/1999/xmldsig-core/sha1"/>
<DigestValue>a53uud43</DigestValue>
</ObjectReference>

Sign "parts" of a document by transforming (via Xpath selection/exclusion) a source document into a derived document.
Lots of discussion on the meaning of the Reference: must it always be explicitly dereferenced for the Signature to validate? If the correct content can be derived from some other method by the application, is this "valid"?

Processing

Reference Validation

locate object and apply Transforms to the specified resource based on each ObjectReference(s) in the SignedInfo element.
calculate digest over each transformed signed object(s)
compare value against DigestValue in SignedInfo for each reference (if any mismatch, validation fails).

Signature Validation

canonicalize the SignedInfo element based on the CanonicalizationMethod, if any, in SignedInfo.
obtain the validation keying info from KeyInfo or externally.
validate the SignatureValue based on the SignatureMethod in the SignedInfo

The Future

November: we have a handful of experimental implementations -- and open issues.
January: close open issues and begin interoperability testing between implementations.