16.2 The Decryption Transform

The Decryption Transform makes it easier to verify XML signatures over data when some of the data has been encrypted before and some after the signature was applied. The signature verifier needs to know which parts to decrypt and which parts to leave encrypted when trying to verify the signature. (This section is based on a W3C Working Draft [Decrypt] but subsequent recommendations will likely have similar characteristics and limitations.)

16.2.1 Introduction to the Decryption Transform

The Decryption Transform works as follows: A Transform is added to appropriate Reference elements in a SignedInfo or Manifest element (see Chapter 10). The Transform takes a list of encrypted parts of the data as parameters. When validating the signature, any other encrypted data encountered within the digested data are decrypted; those listed in the Transform are left encrypted. The concept is simple, but to precisely describe the processing and limitations becomes more complicated.

In protocol applications (see Appendix E), the protocol syntax typically specifies how, in what order, and over which parts of the protocol message signature and/or encryption operations are applied. Therefore, the general mechanism of the Decryption Transform is not essential, although it could be used in certain circumstances. Even in cases where the protocol is very flexible, it would normally be designed to be self-documenting. That is, some indicators would be securely included that enable recipients participating in the protocol to know which decryptions and signature verifications they should perform in what order. Where data of an unknown security structure are forwarded within a protocol message, the data can normally be treated as opaque without further analysis.

For document applications (see Appendix E), the data is usually more free form, and it is desirable for the status of data to be apparent outside of any protocol context. Furthermore, later, independent processes might choose to encrypt parts of the signed data so that the signature no longer verifies. Thus the Decryption Transform is clearly applicable in some document cases.

16.2.2 Decryption Transform Syntax

The algorithm identifier for the Decryption Transform is


which is also the namespace for parameter elements to the Transform. This identifier serves as the value of the Algorithm attribute of a Transform element. It takes, as explicit parameters, an arbitrary number of Except elements, each of which has a URI attribute that points to data that were encrypted during calculation of the signature. These URIs are limited to same-document URIs that point at EncryptedData elements. Example 16-1 shows a Reference element with a Decryption Transform.

Example 16-1 Decryption Transform
 <Reference URI="" xmlns="http://www.w3.org/2000/09/xmldsig#">   <Transforms>     <Transform Algorithm= "http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>     <Transform Algorithm="http://www.w3.org/2001/04/decrypt#"                xmlns:dct="http://www.w3.org/2001/04/decrypt#">       <dct:Except URI="#foo"><dct:Except URI="#bar">     </Transform>   </Transforms>   <DigestMethod Algorithm= "http://www.w3.org/2001/04/xmldsig-more#md5"/>   <DigestValue>qZk+NkcGgWq6PiVxeFDCbJ==</DigestValue> </ds:Reference> 

Following is the schema for the Except element of the Decryption Transform:

 Schema Definition: <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE schema  PUBLIC "-//W3C//DTD XMLSchema 200102//EN"           "http://www.w3.org/2001/XMLSchema.dtd" [ <!ENTITY % p ''>   <!ENTITY % s ''> ]> <schema xmlns='http://www.w3.org/2001/XMLSchema' version='0.1'         xmlns:dt='http://www.w3.org/2001/04/decrypt#'         targetNamespace='http://www.w3.org/2001/04/decrypt#'         elementFormDefault='qualified'> <element name="Except" type="dt:ExceptType"/> <complexType name='ExceptType'>   <attribute name='Id' type='ID' use='optional'/>   <attribute name='URI' type='anyURI' use='required'/> </complexType> 

16.2.3 Decryption Transform Processing

Now we get to the tricky part how to rigorously specify decrypting parts of XML in the XPath data model while minimally changing its serialization in other ways.

The Decryption Transform requires an XPath node-set as input. If the previous Transform or the Reference URI yields an octet stream, it must be parsed. This requirement is only reasonable, as the Transform will look for the EncryptedData elements within the input data. Those that are referenced by the Except parameters are left alone; the others are decrypted and the results plugged in. The XPath data model, on which XML Encryption and Signature are based, does not provide any mechanism for performing "transplant surgery" on an XPath node set, however. As a consequence, much of the processing is defined in terms of substitutions within and augmentations of an octet sequence. In fact, an implementation is merely required to get the same result as it would obtain by following the specified steps. As long as it meets this requirement, it may implement processing in a different fashion.

  1. Serialize the input node-set as specified in the data pipeline discussion in Chapter 10. Remember what part of the resulting octet string came from each EncryptedData that is to be decrypted. If the first element serialized is an EncryptedData, it must be of type "http://www.w3.org/2001/04/xmlenc#Element."

  2. Replace the serializations of the EncryptedData elements to be decrypted with the serializations of their decryption.

  3. Preserve the namespace context of the input node-set by surrounding the octet string with a dummy element. Include in that element all ancestor namespace declarations in scope for the top element of the node set. (This effort requires that the node-set have a single root; that is, one node must be the ancestor of every other node and every attribute and namespace declaration in the node set.) For example, prefix the octet string with " <dummy…>" where "…" is the namespace declarations, and suffix it with "</dummy>".

  4. Preserve the entity context of the input node, if any, by prefixing the octet string with a Document Type Definition having those entity declarations.

  5. Parse the resulting octet string and output the resulting XPath node-set.

16.2.4 Decryption Transform Limitations

The concept of a way to protect signed data such that later modifications can be undone and the signature still verified is quite audacious. Even when it is limited to encryption of XML in the same document as the signature, it cannot be done perfectly.

The processing description given in Section 16.2.3 listed a number of caveats. In addition, the following limitations exist:

  • The Decryption Transform succeeds only if it has access to the keys and algorithms needed to decrypt the data in question.

  • EncryptedKey elements are not handled.

  • Cases of super-encryption of data already encrypted when the Signature element was formed are not handled. (Super-encryption of data unencrypted at signature time can be handled by multiple decryption Transform elements.)

Secure XML(c) The New Syntax for Signatures and Encryption
Secure XML: The New Syntax for Signatures and Encryption
ISBN: 0201756056
EAN: 2147483647
Year: 2005
Pages: 186

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net