XML Encryption Draft Requirements

Draft 2001-March-07

This version:

http://www.w3.org/Encryption/2001/03/07-xml-encryption-req.html

Latest version:

...

Previous version:

http://www.w3.org/Encryption/2001/01/23-xml-encryption-req.html

Editor:

Joseph Reagle <reagle@w3.org>

Copyright © 2001 W3C (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.

3. Requirements

1. Encryption Data Model and Syntax

1. The XML data model used by XML Encryption in identifying or representing data that has been processed must be predicated on:
   1. a simple enumerated subset of InfoSet items (e.g., element, attribute, etc.) and properties {e.g., child, parent, localname, prefix, etc.) {WS}

      The WG is still working on this issue in the context of our XML processing model and its relationship to tree and event based parsers.

2. XML Encryption can be applied to any Web resource -- including non-XML content. {prop1,prop2} Also, see Requirements: Objects.
   1. XML Encryption should be able to work with streaming media. {List: Simon}   However, it is outside the scope of this specification to define approaches to content buffering, incremental delivery, and related issues.  These are application specific.

      This requirement needs to be further specified.

   2. A non-XML object when encrypted is encoded in an instance of XML; when decrypted it must revert to its original media type. {TimBL} 

   I don't find the above statement adequate. I would suggest the following:

   When a non-XML object (i.e., external data) is encrypted, the information necessary to aid the recipient in decrypting the object is encoded in an instance of XML.  It is an application decision whether to include the encrypted object cipher data with this XML, as a base64 encoded CDATA, or to simply reference the external cipher data octet sequence.  In either case, the decrypted data must revert to the media type of the original object.

2. Objects

1. Each encrypted data object should be independent with no required linkage or dependencies with other encrypted data.

2. It should be possible to express key information objects as valid independent XML, or as part of an encrypted data object.

3. It must be possible to indicate the original type (i.e., XML CData, image/gif) of the encrypted data to aid the decryptor in processing it.  For non-XML data, existing MIME type definitions [MIME] should be used. 

4. Binary data must be encoded as Base64 when represented in XML. {FTF1}
5. The specification must not define packaging representations of non XML data (e.g., MIME-objects) other than the encrypted and encoded information appearing within the XML Encryption defined syntax defined by thisthe EncryptedData element.  

Note: We shouldn't reference an element who definition depends on the requirements in this document.

6. The specification must not define a packaging format that describes the relationships between encrypted objects. For instance, the specification will not specify how an application can designate that a set of encrypted objects are actually encryptions over different representations (encodings, compression, etc.) of the same object. {prop3: open issue 2, resolved at FTF1}

3. Processing

1. Parsing  {WS}
   1. XML Encryption applications must be XML-namespaces [XML-namespaces] aware.
   2. XML Encryption applications must be XML Schema [XML-schema] aware in that they create XML encryption instances conforming to the schema definition. {Reagle}
   3. Implementation of the specification should work with existing XML parser and schema implementations.  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.  

 We should just state the requirement and delete the text indicating we've 'demonstrated' something.  I don’t believe this is a difficult requirement to meet as shown by Ed’s code as well as some I’ve written.  However, sample code using non-final syntax and processing rules don't provide proof that the specification will meet this requirement.  The text below captures the last issue above and makes it clear this is out of scope.

However, alterations to particular DOM and/or XML parser implementations may prove beneficial in terms of simplifying application development or improving  runtime efficiency.   These considerations are outside the scope of the XML Encryption specification.

2. XML Instance Validity {WS}
   1. Encrypted instances must be well-formed but need not be valid against the schema associated with the original XML(i.e. applications that encrypt the element structure are purposefully hiding that structure.)
   2. Instance authors that want to validate encrypted instances must do one of the follow:
      1. 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.
      2. Provide a post-encryption schema for validating encrypted instances.
      3. Only encrypt PCDATA text of element content and place its decryption and key information in an external document. (This requires granular detached/external encryption.)
3. The processing model must be described using Information Set terminology and implementations can be based on application specific logic (e.g., XPath and DOM are not required).  {List: Ferguson, FTF1}

   The WG is still working on understanding its processing model requirements.

4. The referencing model must be based on XML Signature's Reference Processing Model [XMLDSIG] with the following two qualifications:
   1. As recommended by [XMLDSIG], where a referencing mechanism supports transforms (e.g., KeyRetreivalMethod and Ciphertext URI) any fragment processing should be specified as part of the transform.
   2. Where a referencing mechanism (e.g., DataReference and KeyReference) does not support Transforms, applications should support same-document XPointers '#xpointer(/)' and '#xpointer(id("ID"))'.

   This document defines the requirements for XML Encryption, so it shouldn't include info from the specification meeting these requirements.

    

5. Transforms  {WS}
   1. Encryption Transforms: The specification must not enable the specification of additional transforms as  part of encrypting and decrypting data; transforms on data being encrypted/decrypted must be done by the application. For example, compression could be done by compressing the content and wrapping that data in an XML compression syntax and then encrypted. {FTF1}
6. Encryption and Signatures
   1. The specification must address recommended approaches for use of 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.  Without this it may be extremely difficult for recipients to determine whether or not to decrypt data prior to signature validation.

       

      1. The interaction of encryption and signing is an application issue and out of scope of the specification. {List: Ashwood, Hirsch, FTF1}

            At this point we should either remove the above or else remove all the other discussion about combining encryption and signature.  My vote is for removing the above text.

       

      1. Applications have the following options:
         1. When data is encrypted, so is its Signature; consequently those Signature you can see can be validated. (However, this is not always easily accomplished with detached Signatures.){List: Finney}
         2. Employ the "decrypt-except" signature transform, being developed as a separate specification. It works as follows: during signature transform processing, if you encounter a decrypt transform, decrypt all encrypted content in the document except for those excepted by an enumerated set of references. {List: Maruyama, FTF1}
7. The encryption and XML processing should be
   1. Fast {List: Ferguson}
   2. Memory efficient {List: Ferguson}
   3. Work with tree and event based parsers {List: Ferguson}

4. Algorithms and Structures

1. The solution must work with arbitrary encryption algorithms, including symmetric and asymmetric keys schemes as well as dynamic negotiation of keying material. {prop1,prop2}
2. The specification must specify or reference one mandatory to implement algorithm for only the most common application scenarios.
   1. Stream Encryption Algorithms {FTF1}
      1. none
   2. Block Encryption Algorithms {FTF1}
      1. AES with CMS keylength is required to implement
      2. 3DES is required to implement -- this may be relaxed when AES as matures.
      3. AES at other keylengths is optional to implement.
   3. Chaining Modes {FTF1}
      1. CBC (Cipher Block Chaining) with PKCS#5 padding is optional to implement.
   4. Key Transport {FTF1}
      1. RSA-OEAP used with AES is required to implement.
      2. RSA-v1.5 used with 3DES is required to implement -- this may be relaxed as AES matures.
   5. Key Agreement {FTF1}
      1. Diffie-Hellman is optional to implement
   6. Symmetric Key Wrap {FTF1}
      1. AES KeyWrap is mandatory -- when it's completely specified.
      2. CMS-KeyWrap Triple-DES and RC2 is required.
   7. Message Authentication {FTF1}
      1. AES/3DES with SHA1 is optional to implement.
      2. XML Signature [XMLDSIG] is optional to implement.
   8. Canonicalization {FTF1}
      1. Canonical XML is required to implement.

         The WG is still working on understanding its processing model requirements.

   9. Compression {FTF1}
      1. none
   10. Initialization Vector {FTF1}
       1. ?

       I suggest we remove this section.  Initialization vector requirements are algorithm specific and they be discussed in that context, if necessary at all.  

        

3. Key Structures
   1. Scope: the only defined key structures must be those required by the mandatory and recommended algorithms. {Reagle}
   2. The specification will not address how to specify the intended recipient of keying information beyond an optional "hint" attribute. {prop3: open issue 1, FTF1}
   3. EnryptedKey element should be a child of a KeyInfo element. {prop3, FTF1} The specification should leverage the XML Signature specification's syntax for keying information (dsig:KeyInfo element) to the maximum extent possible.
   4. Definitions:

      The WG is still considering its requirements with respect to the use of dsig:KeyInfo. Which element is  root, do we use schema class extention or open content models? {List: Reagle}

5. Security

At a minimum, the following types of vulnerabilities shall be discussed.

1. The specification must address Security issues arising from known plain-text and data length informationwhere the following occur: {prop3: issue 5} in software and hardware implementations {List: Lambert
   1. An attacker may know the original structure of the plain-text via its schema. {List: Wiley}
   2. An attacker may know the length and redundancy of the plain-text data. {List: Finney}
2. Processing of invalid decrypted data if an integrity checking mechanism is not used in conjunction with encryption. As already stated, the specification should provide for the optional creation of a checksum over the data encrypted in the ciphertext. (This enables an application to verify the success of the decryption process instead of continuing to process data with the wrong key.) {List: Lambert, FTF1}
3. As already stated, The specification shall warn users about Potential weaknesses resulting from combining the order of signing and encryption operations.
   1. sign before you encrypt:{List: Finney} Weaknesses if a plaintext Hash (inside an XML Signature) is provided along with the encrypted data.  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}
   2. encrypt before you sign: {List: Wang} Potential for fraud if one is induced to digitally sign encrypted data that may not be what the user expected.  

I removed the “already stated” language since I can't seem to find where it was discussed. 

4. The specification should warn application designers and users about revealing information about the encrypted data
   1. in a signature over that data prior to encrypted.
   2. via any semantics inferred from a URI.

    

5. Signature order: The specification's Security Considerations should address weaknesses resulting from:

    Merged this item into #3 above. 

    

   1. sign before you encrypt:{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}

I think I understand the above statement, but isn't the issue the need for an integrity mechanism combined with encryption?  It certainly doesn't seem to be a statement about vulnerabilities from signing before encryption

1. 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}

    I’m not sure exactly what the last sentence is saying..  If I remember the relevant discussion thread,  this was an issue related to signing information without full knowledge of what is being signed.  I reworded to state this above.  If I've misunderstood, someone should rewrite to better explain the issue.

6. Misc

6. Coordination

The XML Encryption specification should meet the requirements of (so as to support) or work with the following applications:

• XW3C XML Signature {Reagle}
• W3C XML Protocols {Reagle}
• Oasis XML-Based Security Services TC (SSTC) {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 Signature WG
• XML Protocol
• XML Schema WG
• XML Core WG
• Internationalization IG

8 Intellectual Property

1. 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.