15.1 Introduction to XML Encryption

"XML Encryption" encompasses the encryption of any kind of data, including the encryption of XML [XMLENC]. What makes it XML Encryption is that an XML element (either an EncryptedData or EncryptedKey element) contains or refers to the cipher text, keying information, and algorithms.

15.1.1 Why Another Encryption Syntax?

As with XMLDSIG, the motivation for a new XML syntax, instead of using existing binary and text syntaxes, was the desire to have encryption information and cipher text as structures that could be created, manipulated, and analyzed with XML tools. You can conveniently encrypt parts of XML documents, thereby smoothly integrating them in XML-based Web services. In addition, you can easily use XML pointers into the structure, make assertions about it, and have it point into other XML structures. Even just displaying and looking at a structure normally in the XML world becomes much easier if the structure is XML.

By the time the XML Encryption effort got rolling, the KeyInfo element existed and a syntax for algorithms had been specified in connection with XMLDSIG. Thus a few of the steps needed to develop XML Encryption had already been taken.

15.1.2 Encryption Granularity

You can use XML Encryption for encrypting arbitrary data. When using it to encrypt XML in place, however, this standard is limited to encrypting an entire element or the entire content of an element. The resulting EncryptedData element then replaces the encrypted element or the encrypted content.

The XML Encryption Working Group [XMLENC WG] has given significant thought to providing some syntax for encrypting attributes or attribute values in place. While there has been interest and the presentation of some informal proposals, a fully specified syntax with processing rules has not been presented to the working group.

15.1.3 Enveloping and Detached Encryption

The EncryptedData element produced by XML Encryption envelopes or references the cipher text. With enveloping encryption (Figure 15-1), the raw encrypted data consists of the CipherValue element's content. With referencing encryption (Figure 15-2), the CipherReference element's URI attribute points to the location of the raw encrypted data.

Figure 15-1. Enveloping encryption

Figure 15-2. Detached encryption

Although "enveloped" signatures make sense (see Chapter 10), the concept of an "enveloped" encryption used in the same way does not work. If you encrypt all information about the encryption, including the algorithm and any keying or other information, that information would become useless that is, you would need to decrypt it to get the information you need to decrypt it. The term "enveloped encryption" refers to something quite different: encrypting data with a symmetric key and then encrypting that key with one or more public keys, as described in Chapter 2.

It's funny how the many questions about "meaning" that plague signatures barely come up with encryption. If something is encrypted, implementers seems to know that it just means that some digital process used the encrypting key and algorithm and changed some plain text into cipher text.

Similarly, at the bit level, a digital signature just means that some digital process with access to the signing key calculated the "signature." If possession of the signing key is controlled, high-level applications can, and frequently do, impute some "meaning" to the signature. Many people go too far, however, equating a digital signature to the conscious approval of some individual person or the like. (In fact, humans are incapable of performing cryptographically strong encryption or signing. Digital hardware and software whose trustworthiness is usually much worse than the cryptographic algorithm employed must mediate such actions.)