XML-Encryption Requirements
Draft 2000-November-15
- This version:
- http://www.w3.org/2000/11/15-xml-encryption-req.html
- Latest version:
- ...
- Previous version:
- http://www.w3.org/2000/10/06-xml-encryption-req.html
- Editor(s):
- Joseph Reagle <reagle@w3.org>
...
Copyright © 2000
The Internet Society & W3C
(MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing
rules apply.
Status of this Document
This is draft intended to capture and focus discussion following the XML Encryption Workshop.
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 {Imamura},
{SL}, {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
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.
This section describes requirements over intended result, how these motivations are
realized are addressed in subsequent sections.
- The XML Encryption specification will describe how to use XML to represent a digitally
encrypted Web resource (including XML itself). {Imamura, SL}
- The specification must provide for the encryption a part or totality of an XML
document
- Granularity of encryption is limited to an element (including start/end tags) or element
content (between the start/end tags). {Imamura, WS}
- Granularity of encryption also includes attribute values. {SL,
WS}[Workshop participants were split on this issue]
- Granularity is limited to the note-set specified by a user specified XPath expression {List: Huck}[Note
there concerns that XPath not be required for XML Encryption.]
Granularity of encryption includes any Information Set Item. {List: Reagle}[No
one strongly advocated this position]
- The specification must provide for recursive encryption (capable of encrypting XML with
portions already encrypted). {Imamura, SL}
The specification must provide for the
separation of encryption information from encrypted data, and support reference mechanisms
for addressing encryption information from encrypted data sections. {HP:
R3.7}
- The XML Encryption specification should strive to limit optionality and maximize
extensibility such that all of the specification can be quickly implemented
- The XML Encryption specification must addresses security concerns arising from the
design and its implementation.
- The mechanisms of encryption must be simple: describe how to encrypt/decrypt digital
content, XML documents, and portions thereof. {Reagle}
- Only enough information necessary for decryption need be provided. {Reagle}
- The specification will not address the confidence or trust applications place in the
provision of a key
- The specification will not address authentication. {List: Reagle, WS}
- The specification will not address authorization and access control. {List: Reagle, Simon, Kudoh, WS}
- If the working group addresses an Information Set representation or canonicalization,
it must use pre-existing data models (e.g., Information Set) and canonicalization
methods (e.g., Canonical XML) unless it can explicitly justify the need for a new one.
{Reagle}
- The specification will define a minimal set of algorithms and key structures necessary
for interoperability purposes. {Reagle}
- Whenever possible, any resource or algorithm is a first class object, and identified by
a URI. {Imamura, SL}
Encryption Data Model and Syntax
- The XML Encryption data model will be predicated on:
- a simple enumerated subset of InfoSet {e.g., element, element-content, attribute-value,
etc.) {WS}
- XPath {List: Huck}
the RDFS schema within the Information Set specification [Infoset]
{Reagle}
[XSet] {Reagle}
- XML Encryption can be applied to any Web resource -- including non-XML content.
{Imamura, SL}
- XML Encryption should be able to work with streaming media. {List:
Simon}
- Encrypted objects are first class objects themselves and consequently can be referenced,
encrypted, and signed. {Reagle}
- Implementation/Design Philosophy
- Parser {WS}
- XML Encryption applications must be XML-namespaces [XML-namespaces]
and XML Schema [XML-schema] aware. {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 Instances {WS}
- Encrypted instances must be well-formed but need not be valid (i.e. applications that
encrypt the element structure are purposefully doing so.)
- Instance authors that want to validate encrypted instances must do one of the follow:
- Write the original schema so as to validate resulting instances and the change in
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.
- The processing model should be based on:
- Application specific logic {List: Ferguson}
- XSLT {List: Ferguson}
- XPath {MyProof}
- XLink {List: Maruyama}
- 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}
- No XML Encryption transforms are defined or reference.
A compression transform should be defined or references.
A new canonicalization transform should be defined or referenced.
- 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.)
- Signature Transform
- 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 may already
be signed and encrypted.
- For the purposes of signature validation, only decrypt those portions specified by the
Signature Transforms. (This makes subsequent encryption difficult; plus leaving the
signature in the clear if the signed data is encrypted allows plaintext guessing attacks.)
{List: Reagle}
- When data is encrypted, so is it's Signature; consequently those Signature you can see
can be validate. (However, this doesn't work
with some cases of detached Signatures.){List: Finney}
- If there is no explicit
<xenc:NoDecrypt>
element within <dsig:SignatureProperty>
,
the default assumption is to decrypt all the encrypted portions before verification. (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}
- Objects
- 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}
- The ways to reference data once encrypted, or supporting information should be
referenced via:
- URI+IDs
- XPath expressions
XLink (provides bi-directional) {WS: not desired in poll}
- The solution must work with arbitrary encryption algorithms, including symmetric and
asymmetric keys schemes as well as dynamic negotiation of keying material. {Imamura, SL}
- 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
- The only defined key structures will be those required by the mandatory algorithms.
{Reagle}
- In addition to key structures required by the mandatory algorithms the following are
specified:
- X is mandatory.
- Y is optional.
- The specification must address security issues arising where:
- 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}
- @@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:
- XML Authorization {List: Scherling,
Damiani}
- [XML Protocols] {Reagle}
- [XML Signature] {Reagle}
To ensure the above requirements are adequately addressed, the XML Encryption
specification must be reviewed by a designated member of the following communities:
- XML Schema Working Group {Reagle}
- XML Core Working Group {Reagle}
- XML Protocol Working Group {Reagle}
- Internationalization Interest Group {Reagle}
- The specification should be free of encumbering technologies: requiring no licensing
fees for implementation and use. {List: Ferguson}
- Imamura
- Another
proposal of XML Encryption, Takeshi Imamura (Mon, Aug 14 2000)
- C2000
- Crypto 2000 XML Encryption BoF [ minutes].
Santa Barbara. August 24 .
- DOM
- Document Object Model Core, Level 3. Arnaud Le Hors. W3C Working Draft.
http://www.w3.org/TR/DOM-Level-3-Core/core.html
- HP
- Requirements
and Goals for the Design of an 'XML Encryption Standard'. Gerald
Huck and Arne Priewe. November 2000.
- List
- XML Encryption List
(an unmoderated and unchartered public list).
- MyProof
- MyProof
Position Paper On XML Encryption
- InfoSet
- XML Information Set, W3C Working Draft. John Cowan.
http://www.w3.org/TR/xml-infoset.
- SL
- XML
Encryption strawman proposal Ed Simon and Brian LaMacchia (Wed, Aug
09 2000)
- WS
- W3C XML Encryption
Workshop [minutes].
SanFrancisco. November 2, 2000.
- XML
- Extensible Markup Language (XML) 1.0 Recommendation. T. Bray, J. Paoli, C. M.
Sperberg-McQueen. February 1998.
- http://www.w3.org/TR/1998/REC-xml-19980210
- XML-C14N
- Canonical XML. Working Draft. J. Boyer. September 2000.
- http://www.w3.org/TR/2000/WD-xml-c14n-20000907
- XML-ns
- Namespaces in XML Recommendation. T. Bray, D. Hollander, A. Layman. January 1999.
- http://www.w3.org/TR/1999/REC-xml-names-19990114
- XML-schema
- XML Schema Part 1: Structures Working Draft. D. Beech, M. Maloney, N. Mendelshohn. April
2000.
- http://www.w3.org/TR/2000/WD-xmlschema-1-20000407/
XML Schema Part 2: Datatypes Working Draft. P. Biron, A. Malhotra. April 2000.
- http://www.w3.org/TR/2000/WD-xmlschema-2-20000407/
- XMLDSIG
- XML-Signature Syntax and Processing. Working Draft. D. Eastlake, J. Reagle, and D. Solo.
http://www.w3.org/TR/2000/WD-xmldsig-core-20000918/
- XSet
- Full Fidelity Information Set Representation. Jonathan Borden. XML-Dev
- http://lists.xml.org/archives/xml-dev/200008/msg00239.html
- URI
- RFC2396. Uniform Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R.
Fielding, L. Masinter. August 1998
http://www.ietf.org/rfc/rfc2396.txt
-