Version: 1.1 2000-11-02
|
Abstract |
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.
 |
Table of Contents |
- 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
 |
Introduction |
- 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 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.
|
Deployed Parsers |
- 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.
|
Detached Document |
- Worst case: Target document allows no added elements.
- Requirement: An option for a detached <Encryption> document.
|
Referencing of Target Document |
- 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.
|
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.
|
Multiple Keys |
- 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.
|
Nested Encryption |
- 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.
|
Overlapping Encryption Targets |
- 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.
|
Encryption-Decryption Processing Rules |
- 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.
|
Encryption-Decryption Process Problems |
- 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...
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].
|
References |