Author: Joseph Reagle

Audience:  WWW10, W3C AC, XML Europe 2001

Question: The status/design of XML Signatures and Encryption

References:

• XML-Signature Syntax and Processing
• Canonical XML
• XML Encryption WG

Cryptography Introduction

Hash (fingerprint, digest): evenly and randomly maps variable length data into a smaller fixed size such that it's "one-way" (hard to find a data object for a given hash result) and "collision-free" (hard to find two data objects with the same hash result).

Secret Key Cryptography (symmetric): the key used for processing is kept as a secret.

Public Key Cryptography (asymmetric): a private/public key pair (inverse of each other) are used to sign (via the private key) and encrypt (via the public key).

Signature: a private key is applied to some data (or its hash)

• authenticity (a specific key was used),
• integrity (the document has been changed),
• and non-repudiation (possessor of the key can not deny it was used.)

Encryption: One often uses a public key (easy to obtain) to send a symmetric key (efficient) for a "session" of communication.

XML Security Introduction

• There is a requirement to ensure the integrity (signature) and confidentiality (encryption) of parts of XML documents.
• Operating on a "bucket of bits" is easy. Operating on parts of XML documents requires the identification and processing of XML in both an abstract (parsed) and consistently serialized (octets) manner.
• These activities are not only applications using XML, they also must address questions about XML, such as canonicalization.
• This is different from access control, authentication and authorization which have fewer issues with XML, but face tricky questions about semantics.

XML Security Scenario

1. FatBrain creates a form that will be filled in by a Alice and sent on to EasyPay.
2. FatBrain signs all of the form except for shipping address and credit card information, which is filled in by Alice.
3. Alice fills in the form, encrypts the payment authorization element in a key shared with EasyPay, and returns it to FatBrain.
4. FatBrain processes the form and confirms the integrity of the order (the book title and price) and passes the encrypted credit card info to EasyPay.

This protocol is faulty, but it demonstrates the use of selective signing and encryption.

dsig:Status

• A joint WG of the IETF/W3C (security and XML coordination/review)
• Canonical XML is a Recommendation / Informational RFC.
• Signature Processing and Syntax in Candidate Recommendation / Proposed Standard. (CR scheduled to close 19-May-2001, IETF last call shortly thereafter.)
  • Implementers have been exchanging and comparing examples on list since summer of 2000. Our implementation report lists five implementors and we already satisfy the Candidate Rec exit criteria.
• Some additional algorithm identifiers (crypto, minimal C14N, and XPath expressions) are being proposed in an informational document.

dsig: Design Principles

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.
   • The "P3P Assurance Profile" Note explores the question of adding semantics to signatures.

dsig:Syntax

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

dsig:Features

• 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).
• Uses XML Schema (and DTD) to describe content model.
• Meets requirement of signing portions of documents via Transforms: processing the document before signing  (e.g., C14N, XPath, etc.)

  <Reference URI="order.xml">
    <Transforms>
      <Transform Algorithm="user-template.xslt"/>
      <Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
    <Transforms>
    <DigestMethod Algorithm="..."/>
    <DigestValue>a234cb</DigestValue>
  </Reference>

dsig:KeyInfo

• KeyInfo permits extensible content; though we provide DSA, RSA, X509, PGP, and SPKI structures (different algorithms and protocols often require different types of keys).
• KeyInfo structures is being used by XML Encryption and other XML security specifications.

dsig:Algorithms

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

• Algorithm identifiers are URIs: extensible, with a few (patent unencumbered) required to implement:

xenc:Status

• A W3C WG, first met March 2001
• Deliverables include
  • XML Encryption Requirements, published as Working Draft in April.
  • XML Encryption Processing and Syntax, still in proposal form.
  • Encryption Signature Transform (a signature transform that allows encryption and signature to be combined), formal specification pending.

xenc: Design Goals

1. Describe how to use XML to represent a digitally encrypted Web resources including XML, and portions thereof. Presently limited to elements (not attribute values).
2. Provide for the separation of encryption information from encrypted data, and support reference mechanisms for addressing encryption information from encrypted data sections and vice versa.
3. Provide for super-encryption (capable of encrypting XML with portions already encrypted)
4. Provide for the secure communication of a session key for subsequent (efficient) communication.

xenc:Example

In the encrypted version of an XML instance, the <EncryptedData> element will appear in place of an encrypted element or its content.

<Animals>
<Cat/>
 <Rodents>
  <Rabbit/>
  <Mouse/>
 </Rodents>
 <Dog/>
<Animals>

<Animals>
<Cat/>
 <EncryptedData xmlns="">
   <CipherData>M3MXCV...
   </CipherData>
 </EncryptedData>
<Dog/>
<Animals>

xenc:Syntax

<EncryptedData Id="" Type="">
  <EncryptionMethod/>?
  <ds:KeyInfo>?
   <enc:EncryptedKey/>?
   ...
  </ds:KeyInfo>?
  <CipherData URI="">iamscrambled</CipherData>
</EncryptedData>

• EncryptedKey is just like EncryptedData, but always carries a (session) key.

xenc:Features

• Element (and element content) encryption.
• Uses structures and features of XML Signature wherever possible.
• Uses XML Schema to describe content model.
• Can be used with XML Signature such that a recipient knows which encrypted blocks were encrypted before and after signature creation: she needs to leave those encrypted before signature generation untouched for the signature to validate.

xenc:Algorithms

• Algorithm identifiers are URIs: extensible, with a few (patent unencumbered) required to implement:

xenc:Issues

• Granularity: haven't received much push back after publication of requirements Working Draft for attribute value encryption.
• ds:KeyInfo reuse: consequences of using xsd:ANY as the extensibility mechanism in xmldsig
• Processing model: are we encrypted octets or abstract items, which data model to use (DOM or Infoset?), does the data model provide URIs for its constituents, and then how do we serialize that data model into octets?