Version: 1.1 2000-11-02
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>.
NOTE: This document is formated so that it can be used as a slide show. The font size of the browser should be adjusted.
- Abstract
Table of Contents
Introduction
Affect On Deployed Parsers- [req-Support-Legacy-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]
- Encryption-decryption Processing Rules
- [req-Encrypt-Decrypt-Remove]
[req-Encrypt-Decrypt-Reverse-Order]
[req-Encrypt-Decrypt-No-Overlap]- Encryption Granularity
References
- MyProof is a small self-financed startup.
- Focused on Internet Commerce, Privacy and Security.
- Currently working with several customers developing XML based solutions.
- Using XML encryption primarily for privacy, security, and selective licensing.
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.
- Supporting customers with legacy XML parsers.
- In some cases we are only allowed to replace element content or attribute values with 64base encoded cyphertext.
- Requirement: Optional support of XML documents that cannot have any XML structure altered.
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] [req-Support-Legacy-Parsers].
- Worst case: Target document allows no added elements.
- Requirement: An option for a detached <Encryption> document.
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.
- Requirement: An option to reference external documents. The <Reference URI='xxx'> attribute meets this requirement.
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.
- To support selective encryption of XML documents that do not allow changes to the XML structure there needs to be a way to reference the target document fragments without adding 'Id' attributes.
- Requirement: There must be an option to use an XPath attribute for the <Reference> element.
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.
- Requirement: This requirement is satisfied by use of multiple <EncryptionInfo> elements.
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: Encryption-Decryption Processing Rules.
- Scenario: A company has an XML employee database. Various fragments of the employee element are are encrypted (salary, medical info, ...). The legal department wants to encypt all the data of a certain employee involved in a legal dispute with the company.
- Requirement: Nested encryptions must be allowed.
- Note: Individual implementions could have encryption-decryption processing rules that prohibit or allow nested 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 processing rules are required
even in some simple cases. See section: Encryption-Decryption Processing
Rules.
- It is possible that sets of document fragments to be encrypted may overlap (example: this could happen if the fragment sets are based on element attribute values).
- Requirement: Overlapping document fragment sets should be allowed.
- Note: Implementations that allow sets of overlapping fragments must establish encryption-decryption processing rules. Without specific processing rules the encryption of one set could hide parts of another set. Or, the decryption of a set may expose parts of another set.
It is also possible that sets of document fragments to be encrypted may overlap (this could happen if the fragment sets are based on element attribute values) [req-Overlapping-Fragments]. This requirement also requires that a encryption-decryption processing rules be established. See section: Encryption-Decryption Processing Rules.
- If an implementation allows mutiple keys, nested encryption,
overlapping encryption, ... encrypt-decrypt processing rules must
be established.
- Encrypt-decrypt processing rules could vary depending on the implementation.
- It may be possible to establish generic processing rules. The XML Encryption Specification should at least meantion and discuss some of the issues.
A few examples of problems:
- If nested encryptions and multiple keys are allowed, a decryption
process would have to decrypt in the reverse order of the
encryptions.
- If overlapping encryptions are allowed, one encryption process can hide parts of a later encryption target.
- If overlapping encryptions are allowed, a decryption could expose parts of another encryption.
- There may be other processing problems...
I am not sure if the Specification of Element-wise XML
Encryption [5] can or
should define encryption-decryption processing rules. 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].