This document describes issues that MyProof has encountered involving XML encryption. It is the intent of this document to either propose or emphasize requirements that are deemed necessary for commercial applications that we have encountered.
This is rough draft intended to be part of discussion in preparation of the XML Encryption Workshop [1]. At this time this document does not represent the official positions or opinions of MyProof. It only represents the opinions of the author.
Please send comments to <steve@myproof.com>.
- Abstract
Table of Contents
Introduction
Affect On Deployed Parsers
Detached Document- [req-Detached-Document]
- Referencing of Target Document
Referencing Target Document Fragments- [req-XPath-Reference-Attr].
- Multiple Keys
- [req-Multiple-Keys]
- Nested Encryption
- [req-Nested-Encryption]
- Overlapping Encryption
- [req-Overlapping-Fragments]
- Multiple Encryption Protocols
- [req-Encrypt-Decrypt-Protocol-Remove]
[req-Encrypt-Decrypt-Protocol-Reverse-Order]
[req-Encrypt-Decrypt-Protocol-No-Overlap]- Encryption Granularity
References
MyProof is working with several customers developing solutions for or based on XML. Some of these solutions involve XML encryption.
MyProof is using selective XML encryption primarily for privacy, security, and selective licensing. However, we are not limited to these applications and are attempting to make any solutions applicable to any private or commercial application.
Some of our applications are being applied to legacy XML applications. Therefore we are very concerned about preserving the validity of the original document. We are also reluctant to force changes to existing applications. And, for economy and ease of implementation, there are some solutions that we prefer over others.
NOTE: We realize that many if not most XML encryption implementations will not encounter the worst-case scenarios that we are suggesting. This document does not attempt to address XML encryption requirements in totality, XML Encryption Requirements[3] . It is addresses only the situations that we have or expect to encounter. We whole-heartedly support the other requirements already existing or to come that address wider and more flexible implementations.
It may difficult to support legacy parsers unless they are widely deployed. But it is possible to provide means that make the support of legacy parsers (even lame ones) easier for implementations. The worst-case scenario is working with legacy parsers that can break when encountering unknown or unexpected XML Infoset items. If the XML Encryption Requirements[3] provide for solutions to this problem then XML encryption applications are much more likely to conform to the Specification of Element-wise XML Encryption[5].
In the worst case an XML encryption implementation may not be allowed to alter the target document structure at all. We have encountered several applications where the customer wishes to encrypt attribute or element CDATA without changing, adding, or deleting any XML tags. Removing the CDATA entirely or removing the CDATA and replacing it with its corresponding cypher text in 64base encoding can accomplish this. We considered embedding encryption information (algorithm, transform, encoding, ...) in the replacement data but this would involve either using XML tags, disguising XML tags, or using a non-XML vocabulary. None of these solutions seemed elegant or desirable. Also, any solutions of this type would be more likely to not conform to the Specification of Element-wise XML Encryption [5]. Therefore all the encryption information (with the exception of the encoded cypher text) must be able to be stored in a detached document [req-Detached-Document] if necessary. This would require that the detached document containing the encryption information be able to accurately reference the fragments encrypted in the target document. See the Section: Referencing Target Document Fragments.
The detached XML encryption information document must be able to reference the target documet or documents. I believe that the URI attribute for the <Reference> element is sufficient for this purpose, Specification of Element-wise XML Encryption [5]. However, the URI attribute requires ID attributes in the target document to reference specific fragments in the target document. This is OK when the implementation is allowed to add ID attributes to the target document. But this is not always the case. Therefore another means of referencing specific items in the target document are required. See the Section: Referencing Target Document Fragments.
We have been using XPath to reference encrypted fragments in the target document. This was an easy solution to implement and works very well for us. Thus we would like to see an XPath attribute added to the <Reference> element in the Specification of Element-wise XML Encryption [5] [req-XPath-Reference-Attr].
MyProof has customers want to apply selective encryption to a target document where different keys are used for different data types [req-Multiple-Keys]. This requirement is satisfied by use of multiple <EncryptionInfo> elements in Specification of Element-wise XML Encryption [5]. However, some implementations will require some encrypt-decrypt protocol to be followed to work properly. See section: Multiple Encryptions.
It is possible that a user may want to apply selective or full encryption to a target document that has already had some selective encryption applied [req-Nested-Encryption]. This requirements seems to be satisfied by use of multiple <EncryptionInfo> elements in Specification of Element-wise XML Encryption [5]. But, some sort of encryption-decryption protocol is required even in some simple cases. See section: Multiple Encryptions.
It is also possible that the document fragments to be encrypted may overlap (this could happen if the fragment scope was based on element attribute values) [req-Overlapping-Fragments]. This requirement also requires that a encryption-decryption protocol be established. See section: Multiple Encryptions.
I am not sure if the Specification of Element-wise XML Encryption [5] can or should define encryption-decryption protocols. But there should at least be some mention of the problems and some recommendation of solutions. Furthermore, there may be many possible protocols, some of which could be complex.
It is possible that a customer may want to apply selective encryption to a target document that has already had some selective encryption applied (Section: Nested Encryption), or that the fragment sets to be encrypted may overlap (Section: Overlapping Encryption). Some sort of encryption-decryption protocol is required even in some simple cases. There should be at least one protocol that requires removing the <EncryptionInfo> element upon decryption [req-Encrypt-Decrypt-Protocol-Remove].
If [req-Encrypt-Decrypt-Protocol-Remove] is followed and if decryptions are applied in reverse order of the encryptions, no problems arrise. Thus applying decryptions in reverse order of encryptions would be another protocol rule [req-Encrypt-Decrypt-Protocol-Reverse-Order]. Following these two rules is required if any encryption document fragments are nested or overlapping.
If a user finds [req-Encrypt-Decrypt-Protocol-Reverse-Order] too restrictive they may be able to decrypt in any order if there are no nested or overlapping encryption document fragments [req-Encrypt-Decrypt-Protocol-No-Overlap].
We believe the "XML Element-wise Encryption Specification" should be named "XML Encryption Specification" to reflect that the encryption granularity is smaller than that of XML elements.