10.1 Introduction to XML Digital Signatures

What does a digital signature "mean"?

In reality, it merely associates some data with a "key." The application that generates the signature must have access to the data to be signed and the signature generation key. Later, an application can verify the signature if it has access to the signed data and to the signature verification key. (The verification key may or may not be the same as the generation key, depending on the kind of authentication in use.) If the signature is verified, the verifier knows that either some application with the generation key has produced the signature or an adversary has broken the cryptographic algorithms. Let's assume good cryptographic algorithms and good control over who has a copy of the key. If data are signed at some place and time and later verified at a different place or time, you can be confident of two things:

1. It was signed with the key.

2. It has not been modified from its original value.

Note that these points do not mention "meaning" at all. Any "meaning" given to a digital signature, beyond strongly connecting some data with a key, is an interpretation imposed by a particular application. True, it is common for the signed "data" to include structures intended to be interpreted as assertions. For example, such an assertion could be a claimed date of signing or an indication of whether some "person" who should have control over the key and its use is stating, agreeing to, or merely witnessing the data. It is very tempting, if the data appears to be human-readable text and the key is associated in some way with a particular person, to conclude that that person is "saying" what appears to be in the data. But perhaps some secure channel computer process is working on behalf of the person who has signed the data just for integrity assurance during transport without any idea of what the data "says." Or perhaps a computer program has been duped into signing the data. In any case, from the point of view of the mechanics of generating and validating signatures, the data consist of just a pile of 1s and 0s; all "human meaning" interpretations take place at a higher application level.

Why a New Form of Signature?

One preliminary question you might ask is, "Why create a new format for signatures?" After all, things work with existing signature formats. For example, the binary format in PKCS#7 [RFC 2315] uses [ASN.1, DER] syntax, and the binary format in PGP [RFC 2240] uses its own binary syntax. If you want a printable form of these binary signature blobs, you could encode them into ordinary printable characters by using base-64 [RFC 2045] or the like.

For XML systems, the signature object itself must conform to XML syntax. Only then can you use XML tools to manipulate pieces of it, have it easily point into other XML structures so you can sign parts of XML documents, easily point into it and make assertions about it or parts of it, and use XML tools to display it.

During the development of the XMLDSIG standard, several people joined the working group mailing list and posted messages that said something like the following: "What in the world are you guys doing? You should just define a simple XML envelope to go around Z, and everyone's problem will be solved. I'm shocked that you are defining a new signature format that will be a lot of work for me to implement…."

Z was always the correspondent's favorite existing binary signature standard. Of course, it was different for each person who posted such a note! These people just wanted something like a <PKCS7signature/> element, for which the content was a PKCS7 binary blob encoded into printing characters. That would have meant using PKCS7 as an example that everyone implementing XMLDSIG would need not just an XML parser and generator but also one for ASN.1/DER. Useful signature properties or the like would be opaquely buried inside this binary blob rather than being accessible and manipulatable XML. In other words, what these people wanted wasn't XML signatures but their own favorite non-XML signature with a very thin XML veneer.

The key characteristic of XML Digital Signatures (XMLDSIG) is that the signature object itself appears in XML syntax. The data being signed can consist of XML, but that is not required. The data could also be a binary file such as a GIF image or the result of querying a database through a URI or, because one XMLDSIG Signature element can authenticate multiple pieces of data, all of these at the same time. XML digital signatures can sign anything you can reference through a URI (see Chapter 7). Even more flexibly, they can sign anything you can derive with an algorithmic transformation from data that a URI references!

Enveloping, Enveloped, and Detached Signatures

As well as varying by data type, you can classify things that XMLDSIG signs as to whether the data being signed appears in one of the following places:

• Inside the XMLDSIG element, which is called an enveloping signature (see Figure 10-1).

  Figure 10-1. An enveloping signature

  

• Outside of, but surrounding, the XMLDSIG element, which is called an enveloped signature (see Figure 10-2).

  Figure 10-2. An enveloped signature

  

• Outside and disjoint from the XMLDSIG element, which is called a detached signature (see Figure 10-3). Note that detached signed data can appear either in the same document as the XMLDISG element or elsewhere.

  Figure 10-3. A detached signature over two data items

  

Because XMLDSIG elements can sign multiple pieces of data, they can be any two or all three of these kinds of signatures enveloping, enveloped, or detached at the same time.