HTTP/2 200 date: Thu, 09 Oct 2025 05:19:37 GMT content-type: text/html; charset=iso-8859-1 content-encoding: gzip last-modified: Fri, 03 Dec 1999 21:18:34 GMT cache-control: max-age=21600 expires: Thu, 09 Oct 2025 11:19:37 GMT vary: Accept-Encoding x-backend: www-mirrors x-request-id: 98bb6c8f9bbacb77 strict-transport-security: max-age=15552000; includeSubdomains; preload content-security-policy: frame-ancestors 'self' https://cms.w3.org/ https://cms-dev.w3.org/; upgrade-insecure-requests cf-cache-status: BYPASS set-cookie: __cf_bm=vLJSZL7ZOlqhFGpckPkkKp4eAdE5sKFmy2ABkcq2XX4-1759987177-1.0.1.1-tkD54EuCUI_L6xwvTQ25DWUe2qLrh7RhiaZKyTJ87_pgS_lsMID5fFUVkSMt1PMyp4IBZie_PdWC73DO5u4TVIumPRPb05jmFoGlT30U9ls; path=/; expires=Thu, 09-Oct-25 05:49:37 GMT; domain=.w3.org; HttpOnly; Secure; SameSite=None server: cloudflare cf-ray: 98bb6c8f9bbacb77-BLR alt-svc: h3=":443"; ma=86400

Author: Joseph Reagle

Audience: XML'99

Question: What does XML Signature look like, what are the issues?

References:

1. https://www.w3.org/TR/1999/WD-xmldsig-core-19991119/ [revised WD]
2. https://www.w3.org/TR/1999//WD-xmldsig-requirements-19991014 [Going to InfoRFC]

XML Signature

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

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

Agenda

1. Working Group Background
2. Design Principles/Goals
3. Technical Design and Open Issues
4. 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

1. The specification must describe how to use XML syntax to represent a signature over digital content (and XML content in particular).
2. XML-signatures are generated from a hash over a list of references and the digest value of the references' content.
3. 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="https://www.w3.org/1999/10/signature-core">
  <SignedInfo> ; scope of sig processing
    <CanonicalizationMethod ; for SignedInfo
      Algorithm="https://www.w3.org/1999/xmldsig-core/c14n"/>
    <SignatureMethod Algorithm="dsig:dsaWithSHA-1"/> 
    <ObjectReference URI="www.mypage.com" ; points to resource
      <DigestMethod Algorithm="https://...sha1"/>
      <DigestValue>a53uud43</DigestValue>
    </ObjectReference>
    <ObjectReference IDREF="#timestamp" ; points to resource
      Type="https://www.w3.org/1999/sig1/signatureattributes">
      <Transforms> ; source tree to output octect
        <Tranform name="https://www.w3.org/1999/xmldsig-core/c14n"/>
      </Transforms>
      <DigestMethod Algorithm="https://...sha1"/>
      <DigestValue>a53uud43</DigestValue>
    </ObjectReference>
  </SignedInfo>
  <Object ID="timestamp">
    <timestamp about="#5"
         xmlns="https://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="https://www.w3.org/.../xml-c14n"/>
    <SignatureMethod Algorithm="dsig:dsaWithSHA-1"/> 
    <ObjectReference URI="https://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="https://www.w3.org/1999/xmldsig-core/SignatureAttributes">
  <Transforms> ; source tree to output octect
     <Transform Algorithm="https://w3.org/1999/XPath"/>
     <Transform Algorithm="https://w3.org/1999/xmldsig-core/c14n"/>
   </Transforms>
  <DigestMethod Algorithm="https://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

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

Signature Validation

1. canonicalize the SignedInfo element based on the CanonicalizationMethod, if any, in SignedInfo.
2. obtain the validation keying info from KeyInfo or externally.
3. 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.