Author: Joseph Reagle

Audience:  WWW2002

Question: The status/design of XML Signatures, Encryption, and Key Management

References:

• XML-Signature Syntax and Processing
  • Canonical XML
  • Exclusive XML Canonicalization
  • XML Signature XPath Filter 2.0
• XML Encryption Syntax and Processing
  • Decryption Transform for XML Signature
• XML Key Management Specification

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 between the parties.

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.

Key Management: How to obtain the real key of the person with whom you want to communicate. This typically involves chains of signatures on a key that must be checked/validated.

XML Security Introduction*

• There is a requirement to ensure the integrity (via signature) and confidentiality (via 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 (data model) and consistently serialized (octets) manner.
• These activities are not only applications using XML, they also must address questions about XML, such as selecting subsets of a document, and then canonicalizing them.
• 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. BookStore creates a form that will be filled in by a Alice and sent on to EasyPay.
2. BookStore 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 BookStore.
4. BookStore 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) coming to a close.
• REC: XML-Signature Syntax and Processing
  • REC: Canonical XML
  • REC: Exclusive XML Canonicalization
  • REC: XML Signature XPath Filter 2.0
• The XML-Signature Recommendation has 15 implementation reports.

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).
• 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="https://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="https://www.w3.org/2000/02/xmldsig#dsa"/>

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

xenc:Status*

• REC: XML Encryption Syntax and Processing
  • REC: Decryption Transform for XML Signature

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 and content (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>
  <Beaver/>
  <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.
• 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:

xkms:Introduction*

Neither XML Signature nor Encryption specify how to obtain trustworhty keys.

There's a body of existing (non-XML) standards and infrastucture to satisfy this requirement.

XKMS provides a Web/XML based interface to existing infrastructure for XML based applications.

xkms:Example Request*

<?xml version="1.0" encoding="utf-8"?>
<LocateRequest xmlns:ds="https://www.w3.org/2000/09/xmldsig#" 
      xmlns:xenc="https://www.w3.org/2001/04/xmlenc#" 
      Service="https://test.xmltrustcenter.org/XKMS"
      xmlns="https://www.w3.org/2002/03/xkms#">
  <RespondWith>KeyValue</RespondWith>
  <QueryKeyBinding>
    <KeyUsage>Encryption</KeyUsage>
    <UseKeyWith Application="urn:ietf:rfc:2633" Identifier="bob@bobcorp.test" />
  </QueryKeyBinding>
</LocateRequest>

xkms:Status*

• NOTE: XKMS Requirements
• (Last Call) Working Draft: XKMS (2.0)
  • (Last Call) Working Draft: XKMS (2.0) Bindings