Status of this Document
This is draft intended to capture and focus discussion prior to the 01 March 2001
face-to-face meething. This document has no standing whatsoever.
This document does not represent consensus. Instead, it is the author's attempt to show
requirements and alternatives within the scope already out-line in the ongoing
discussions. Furthermore, it may include things that are not well stated, as well as
provocative or contrary positions (or alternative wordings) in order to elicit review and
discussion. It's roughly based on the authors understanding of {prop1},
{prop2}, {prop3}, {C2000},
{WS}, and other discussion and proposals, though my
characterizations may be in error. Positions which are potentially in conflict are
specified as a list of lettered points. For example:
- Extensibility
- Position
- Alternative/Contrary Position
Some alternatives are stricken to represent that a newer proposal was considered or
consensus seems counter to that proposal, but I'm not yet confident enough (or things can
be learned) by not yet deleting it from the document.
Citation of a source (e.g., {source}) in no way indicates that is the originator or
sole supporter of that requirement. Instead, it helps track at least one source/motivation
of the requirement.
Please send comments to the editor <reagle@w3.org>
and cc: the list xml-encryption@w3.org (archives) Publication of
this document does not imply endorsement by the W3C membership. This is a draft document
and may be updated, replaced or obsoleted by other documents at any time.
Abstract
This document lists the design principles, scope, and requirements for the XML
Encryption. It includes requirements as they relate to the encryption syntax, data model,
format, cryptographic processing, and external requirements and coordination.
The XML 1.0 Recommendation [XML] describes the syntax of a class of
data objects called XML documents. There is interest in a specification of XML syntax and
processing for encrypting digital content, including portions of XML documents and
protocol messages. This documents provides requirements for such an activity -- as well as
provocation and alternative requirements.
1. Encryption Data Model and Syntax
- The XML data model used by XML Encryption in identifying or
representing data that has been processed will be predicated on:
- a simple enumerated subset of InfoSet items and properties {e.g., element, character,
attribute, attribute normalized-value, etc.) {WS}
XPath {List: Huck}
the RDFS schema within the Information Set specification [Infoset]
{Reagle}
[XSet] {Reagle}
- DOM node lists {prop3}
- XML Encryption can be applied to any Web resource -- including non-XML content. {prop1,prop2} Also, see Requirements: Objects.
- XML Encryption should be able to work with streaming media. {List:
Simon}(Does
this necessitate detached encryption? -JR)
- A non-XML object when encrypted is encoded in an instance of XML; when decrypted it must
revert to its original media type. {TimBL}
- Encrypted objects are first class objects themselves and consequently can be referenced,
encrypted, and signed. {Reagle}
- The specification may provide for encrypted representations of non XML data (e.g.,
MIME-objects).
- The specification must define an analog of xmldsig:Object that provides an encoding and
type description for the encoded object. {Reagle:xmldsig}
- The specification must not define any representation formats. {HP:
R2.2, List: Huck}
- Binary data may be represented as
- Base64 encoding only. {Reagle:xmldsig}
- XML Schema 'base64' and 'hex' only. {HP: R3.5.2, List: Huck}
- Should we provide a packaging format to describe that multiple encrypted objects are
related (e.g., different encodings of the same document? {prop3:
open issue 2}
- Implementation/Design Philosophy
- Parser {WS}
- XML Encryption applications must be XML-namespaces [XML-namespaces]
aware.
- XML Encryption applications must be XML Schema [XML-schema] aware in that they create XMl
encryption instances conforming to the schema definition. {Reagle}
- Implementation of the specification should have a minimal affect upon XML parser and
schema implementations. While {WS:Simon}
demonstrated that XML-encryption functionality did not necessarily require any changes to
particular DOM and XML parser implementations, it may be necessary for implementors to
tweak their parsers as needed.
- XML Instance Validity {WS}
- Encrypted instances must be well-formed but need not be valid (i.e. applications that
encrypt the element structure are purposefully hiding that structure.)
- Instance authors that want to validate encrypted instances must do one of the follow:
- Write the original schema so as to validate resulting instances given the change in its
structure and inclusion of element types from the XML Encryption namespace.
- Provide a post-encryption schema for validating encrypted instances.
- Only encrypt PCDATA text of element content and place
DecryptionInfo
and KeyInfo
in an external document. (This requires granular detached/external
encryption.)
- The processing model should be based on:
- Application specific logic {List: Ferguson}
XSLT {List: Ferguson}
XPath {MyProof}
XLink {List: Maruyama}
- The referencing model (how to identify the
things being encrypted) will be based on:
- URIs or ID fragments
- URI+IDs (These then have to be expressed as an XPointer unless there are transforms.)
- XPath expressions (These then have to be expressed as an XPointer unless there are transforms.)
XLink (provides bi-directional) {WS: not desired in poll}
- The encryption and XML processing should be
- Fast {List: Ferguson}
- Memory efficient {List: Ferguson}
- Work with tree and event based parsers {List: Ferguson}
- Transforms {WS}
- Encryption Transforms
- The specification must enable the specification of additional transforms as part of
encryption processing using a method similar to that of XML Signature (However in
encryption they are applied in reverse order {List: Huck}).
This would enable user specified transforms such as compression, canonicalization,
advanced padding and signature processing. {HP: R3.4.1, List: Huck}
A compression transform should be defined or referenced.
- Canonicalization? (Canonical XML is XML, but can be verbose.)
- If we decide against attribute encryption, then one could use an XSLT transform to
convert from the original document into one an instance where everything is captured as a
element+content. {Reagle, List: Hallam-Baker}
- The specification must not enable the specification of additional transforms; transforms
must be done by the application and represented in their own syntax (e.g., compression is
done by compressing content and rapping that data in an XML compression syntax.)
- Encryption and Signatures
- The specification must address how to use XML Signature with XML Encryption such that
multiple parties may selectively encrypt and sign portions of documents that might already
be signed and encrypted.
- The order of encryption and decryption is an application issue and out of scope. {List: Ashwood,
Hirsch}
- When data is encrypted, so is its Signature; consequently those Signature you can see
can be validated. (However, this doesn't work
with some cases of detached Signatures.){List: Finney}
- Capture the order of processing:
When data is encrypted, the ID
value that used to correspond to the
content and was referred to by a Signature, is now given to the ID
of the
Encryption content. Processors first try to signature validate the encrypted element, if
that fails they then try to decrypt it. {List: Hirsch}
(This only works when the signature/encryption is of the same granularity, what happens if
you want to encrypt children of the element signed? {List: Reagle})
- A separate XML structure contains a stack of processing (signing/encrypting) steps; you
can't insert this as attributes directly.into the XML as it would then break signatures. {List: Hallam-Baker/Reagle}
- For attached signatures, create nesting elements such as <exposedSignature>,
<hiddenSignature>, <signThenEncrypt>, <encryptThenSign> {List: Ashwood}
During signature validation, only decrypt those portions specified by a
decyrption signature transform. (However, this makes subsequent encryption difficult; plus
leaving the signature in the clear if the signed data is encrypted allows plaintext
guessing attacks.) {List: Reagle}
During signature validation, decrypt all portions except those with a <xenc:NoDecrypt>
element within <dsig:SignatureProperty>
. (This is an odd change to
Signature Transform semantics; plus leaving the signature in the clear if the signed data
is encrypted allows plaintext guessing attacks.) {List: Maruyama}
- During signature transform processing, if you encounter a decrypt transform, decrypt all
encrypted content in the document except for those excepted by its EncryptedReference
child element. {List: Maruyama}
(Solves earlier encryption, detached and semantic concerns, but leaves digest values in
the clear (these two should be encrypted. Also, problem of "3.b Problem of
"Alice Encrypts element A and the Signature over the parent of A. Bob Encrypts
element B (sibling of A) but *not* the Signature since he doesn't know about it. Alice
then decrypts A and it's Signature, providing information to a subsequent plain text
attack." {List: Reagle})
- Signature order (which is more secure?)
- sign before you encrypt and encrypt signature.{List: Finney}
(This can be problematic as, "the only way to achieve secure channels is to encrypt
first, then MAC. Though signature is different from MAC, but we should keep in mind that
digital signature is an extension of MAC." {List: Wang})
- encrypt before you sign. {List: Wang}
(This can be problematic as, "it was shown that by choosing your RSA key pair, and
keeping the factors of N, you could create many different statements easily, with very
real possibilities for fraud. {List: Ashwood}).
- The solution must work with arbitrary encryption algorithms, including symmetric and
asymmetric keys schemes as well as dynamic negotiation of keying material. {prop1,prop2}
- The specification must specify or reference one mandatory to implement algorithm for
only the most common application scenarios. (All options result from Schaad's Algorithm
Selections recommendations unless noted.)
- Stream Encryption Algorithms
- none
RC4 is optional.
- Block Encryption Algorithms
- AES with CMS keylength is required to implement
- AES at other keylengths is optional to implement.
- TripleDES is optional to implement.
- IDEA as optional to implement {List: Priewe}
- Chaining Modes
- CBC (Cipher Block Chaining) with PKCS#5 padding is optional to implement.
CTS (Cipher Text Stealing).
- Key Transport
- RSA-OEAP used with AES is required to implement.
- RSA-v1.5 used with TripleDES is optional to implement.
- ECIES {List: Blake-Wilson}
- Key Agreement
- none
- Diffie-Hellman is optional to implement
- ECDH {List: Blake-Wilson}
- Symmetric Key Wrap
- CMS-KeyWrap is required for wrapping Triple-DES and RC2 keys
- AES KeyWrap from the NSA is mandatory -- when its completely specified.
- Message Authentication
- XML Signature is optional to implement
- Canonicalization
- none
- Canonical XML is required to implement.
- Compression
- none
- A method for XML redunancy removal should be optional (and should be free of encumbering
IP claims) {List: Huck}
- Password Derivation Algorith
- none
- Key Structures
- Scope
- The only defined key structures will be those required by the mandatory algorithms.
{Reagle}
- Should we support encryption of keying material to multiple recipients within a single
EncryptedKey element? {prop3: open issue 1}
- Semantics {prop3: open issue 4}
- EncryptedData may contain EncryptedKey and/or KeyInfo child elements. The EncryptedKey element may also contain a
KeyInfo child element. (This might be considered complex). {prop3}
- EnryptedKey element is a child of a KeyInfo element, which might also include KeyInfo.
(This allows unbounded nesting.) {prop3}
- Definition
- Can dsig:KeyInfo be incoporparated directly into the encryption instance? (Which element
is root, do we use schema class extention or open content models?) {List: Reagle}
- The specification must address security issues arising where the following occur: (does
this necessitate padding? {prop3: issue 5}
- An attacker may know the original structure of the plain-text via its schema. {List: Wiley}
- An attacker may know the length and redundancy of the plain-text data. {List: Finney}
- An attacker may have access to an oracle which encrypts attacker chosen plain-text
repeatedly. {Reagle}
- The specification should support the use of hardware implementation of the encryption
processing (which is specified as part of the algorithm identifier). {List:
Lambert}
- Integrity of Encrypted Data
- "The specification must provide mechanisms to check the integrity of decrypted
data. Mandatory to implement algorithms should include integrity check mechanisms." {List: Lambert}
- "Given the history I think that authentication and encryption in one operation
needs to be considered as a separate algorithm rather than supporting mix 'n match
schemes. Most authentication with encryption schemes will fail with RC4 and similarly
constructed ciphers." {List: Hallam-Baker}
- Should we define a structure that sits outside an EncryptedData by which you assert
"this key was used to encrypt the following Referents. {prop3:
open issue 3}
- @@Where did we stand on the issue of email headers encryptor/recipient?
The XML Encryption specification should meet the requirements of (so as to support) or
work with the following applications:
To ensure the above requirements are adequately addressed, the XML Encryption
specification must be reviewed by a designated member of the following communities:
- The specification should be free of encumbering technologies: requiring no licensing
fees for implementation and use. {List: Ferguson}
"Members
of the XML Encryption Working Group and any other Working Group constituted within the XML
Encryption Activity are expected to disclose any intellectual property they have in this
area. Any intellectual property essential to implement specifications produced by this
Activity must be at least available for licensing on a royalty-free basis. At the
suggestion of the Working Group, and at the discretion of the Director of W3C,
technologies may be accepted if they are licensed on reasonable, non-discriminatory
terms." XML
Encryption Charter.