IETF-45 xmldsig

Author: Joseph Reagle

Audience:� XML2000

Question: Overview of Signature

References:

• XML-Signature Syntax and Processing
• Canonical XML

XML Signature

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

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

XML Signature Status

• A joint WG of the IETF/W3C.
  • Security and XML Coordination/Review
• Signature Processing and Syntax in Candidate Recommendation (soon Proposed Standard)
• Canonical XML is Candidate Recommendation (soon Informational RFC)
• Implementors have been exchanging and comparing examples on list since the summer.

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.

Design Overview

<Signature> 
  <SignedInfo>
    (CanonicalizationMethod)?
    (SignatureMethod)
    <Reference (URI=)? >
      (Transforms)?
      (DigestMethod)
      (DigestValue)
    </Reference>)+
  </SignedInfo>
  (SignatureValue) 
 (KeyInfo)?
 (Object)*
</Signature> 

Design Example

[s01] <Signature Id="MyFirstSignature" xmlns="http://www.w3.org/2000/02/xmldsig#"> 
[s02]   <SignedInfo> 
[s03]     <CanonicalizationMethod Algorithm="http://www.w3.org/TR/2000/WD-xml-c14n-20000119"/> 
[s04]     <SignatureMethod Algorithm="http://www.w3.org/2000/02/xmldsig#dsa"/> 
[s05]     <Reference URI="http://www.w3.org/TR/2000/REC-xhtml1-20000126/"> 
[s06]       <Transforms> 
[s07]         <Transform Algorithm="http://www.w3.org/2000/02/xmldsig#c14n"/> 
[s08]       </Transforms> 
[s09]       <DigestMethod Algorithm="http://www.w3.org/2000/02/xmldsig#sha1"/> 
[s10]       <DigestValue>j6lwx3rvEPO0vKtMup4NbeVu8nk=</DigestValue> 
[s11]     </Reference> 
[s12]   </SignedInfo> 
[s13]   <SignatureValue>MC0CFFrVLtRlk=...</SignatureValue> 
      ...
[s17] </Signature>

Features of Design

• Works with enveloped signatures (signature within content being signed), enveloping signatures (content is within signature being signed) and detached signatures (over data�external to the signature document).
• Meets requirement of signing portions of documents via transforms (i.e., XPath)
• Very extensible
• Uses XML Schema (and provides a DTD).

URI and Processing Model

• dereferencing and transforms operate over octets or XPath node-sets. Conversion from one to the other requires canonicalization or parsing.
• Absolute URI and null-URI/bare-name-XPointer support in the URI.
• Other XPath, or XPointer processing should be specified as a specific Transform.

URI="http://example.com/bar.xml"

Identifies the octets that represent the external resource 'http//example.com/bar.xml', that is probably XML document given its file extension.

URI="http://example.com/bar.xml#chapter1"

Identifies the element with ID attribute value 'chapter1' of the external XML resource 'http://example.com/bar.xml', provided as an octet stream. (Not recommended)

URI=""

Identifies the nodeset (minus any comment nodes) of the XML resource containing the signature

URI="#chapter1"

Identifies a nodeset containing the element with ID attribute value 'chapter1' of the XML resource containing the signature. XML Signature (and its applications) modify this nodeset to include the element plus all descendents including namespaces and attributes -- but not comments.

KeyInfo

[s14]�� <KeyInfo>
[s15a]��� <KeyValue>
[s15b]����� <DSAKeyValue>
[s15c] �������<P>...</P><Q>...</Q><G>...</G><Y>...</Y>
[s15d]����� </DSAKeyValue>
[s15e]��� </KeyValue>
[s16]�� </KeyInfo>

• KeyInfo permits extensible content; though we
  • Provide explicit placeholders for X509, PGP, and SPKI structures.
  • Define DSA and RSA key structures.

Objects

[p00] <Signature Id="MySecondSignature" ...> 
[p01]  <SignedInfo> ...
[p02]   <Reference URI="http://www.w3.org/TR/xml-stylesheet/">... 
[p03]   <Reference URI=" #AMadeUpTimeStamp "  
[p04]         Type="http://www.w3.org/2000/02/xmldsig#SignatureProperty">...
[p08]  </SignedInfo>  
[p09]  ...  
[p10]  <Object> 
[p11]   <SignatureProperties Id="AMadeUpTimeStamp"> 
[p12]     <SignatureProperty Target=" #MySecondSignature "> 
[p13]        <timestamp xmlns="http://www.ietf.org/rfcXXXX.txt">  
[p14]          <date>19990908</date>  
[p15]          <time>14:34:34:34</time>  
[p16]        </timestamp>  
[p17]     </SignatureProperty> 
[p18]   </SignatureProperties> 
[p19]  </Object>  
[p20]</Signature> 

Algorithms

[s04]�� <SignatureMethod Algorithm="http://www.w3.org/2000/02/xmldsig#dsa"/>

• Algorithm identifiers are URIs: extensible, with a few required to implement:

Near Future

• XML Signature Interoperability matrix shows multiple interoperable implementations (sans minimal-canonical and schema validation). Specification could advance quickly but IETF process requires a six month Proposed Standard period.
• Canonical XML interoperability matrix shows multiple interoperable implementations, plan to enter Proposed Recommendation in January (should be published as Informational RFC shortly.)
• Discussion on XML encryption and XML certificate structures pops up frequently: not part of charter.
• There was an XML Encryption Workshop and there is an XML Encryption Activity Proposal before the W3C Advisory Committee.