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:
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.
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:
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.