XML Encryption Syntax and Processing

WG Working Draft 11-May-2001

This version:
$Revision: 1.18 $ on $Date: 2001/06/12 19:06:36 $ by $Author: reagle $
Latest version:
Previous version:
This draft is based on the 15-December-2000 Proposal [prop3] by Dillaway, Fox, Imamura, LaMacchia, Maruyama, Schaad, and Simon.


This document specifies a process for encrypting data and representing the result in XML. The data may be arbitrary data (including an XML document), an XML element, or XML element content. The result of encrypting data is an XML Encryption element which contains or references the cipher data.

Status of this document

This is an editors' copy that has absolutely no standing.

Table of Contents

  1. Introduction
    1. Editorial and Conformance Conventions
    2. Design Philosophy
    3. Versions, Namespaces and Identifiers
    4. Acknowledgements
  2. Encryption Overview and Examples
    1. Encryption Granularity
      1. Encrypting an XML Element
      2. Encrypting XML Element Content (Elements)
      3. Encrypting XML Element Content (Character Data)
      4. Encrypting Arbitrary Data and XML Documents
      5. Super-Encryption: Encrypting EncryptedData
    2. EncryptedData and EncryptedKey Usage
      1. EncryptedData with Symmetric Key  (KeyName)
      2. EncryptedKey (ReferenceList, KeyRetrievalMethod,CarriedKeyName)
  3. Encryption Syntax
    1. The EncryptedType
    2. The CipherData Element
      1. The CipherReference Element
    3. The EncryptedData element
    4. Extensions to KeyInfo Element
      1. The EncryptedKey Element
      2. The KeyRetrievalMethod Element
      3. The ReferenceList Element
  4. Processing Rules
    1. Encryption
    2. Decryption
    3. Encrypting XML
  5. Algorithms
  6. Security Considerations
  7. Schema, DTD, Valid Examples
  8. Issues
  9. References

1 Introduction

This document specifies a process for encrypting data and representing the result in XML. The data may be arbitrary data (including an XML document), an XML element, or XML element content. The result of encrypting data is an XML Encryption EncryptedData element which contains (via one of its children's content) or identifies (via a URI reference) the cipher data.

When encrypting an XML element or element content the EncryptedData element replaces the element or content (respectively) in the encrypted version of the XML document.

When encrypting an entire XML document, the EncryptedData element may become the root of the new document. And when encrypting arbitrary data, the the EncryptedData element may become the root of a new XML document or become a child element in an application-chosen XML document.

1.1 Editorial and Conformance Conventions

This specification uses XML Schemas [XML-schema] to describe the content model.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in RFC2119 [KEYWORDS]:

"they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)"

Consequently, we use these capitalized keywords to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. These key words are not used (capitalized) to describe XML grammar; schema definitions unambiguously describe such requirements and we wish to reserve the prominence of these terms for the natural language descriptions of protocols and features. For instance, an XML attribute might be described as being "optional." Compliance with the XML-namespace specification [XML-NS] is described as "REQUIRED."

1.2 Design Philosophy

The design philosophy and requirements of this specification are addressed in the XML Encryption Requirements document [EncReq].

1.3 Versions, Namespaces and Identifiers

No provision is made for an explicit version number in this syntax. If a future version is needed, it will use a different namespace. The experimental XML namespace [XML-NS] URI that MUST be used by implementations of this (dated) specification is:


Additionally, this specification makes use of the XML Signature [XMLDSIG] namespace and schema definitions


This namespace is also used as the prefix for algorithm identifiers used by this specification. While applications MUST support XML and XML namespaces, the use of internal entities [XML] or our "enc" XML namespace prefix and defaulting/scoping conventions are OPTIONAL; we use these facilities to provide compact and readable examples.

1.4  Acknowledgements

The contributions of the following working group members to this specification are gratefully acknowledged:


2 Encryption Overview and Examples (Non-normative)

This section provides an overview and examples of XML Encryption syntax. The formal syntax is found in Core Encryption Syntax (section 3); the specific processing is given in Processing Rules (section 4).

Expressed in shorthand form, the EncryptedData element has the following structure:

<EncryptedData (Id='')? (Type='')?>
    <CipherValue>(encrypted character data)</CipherValue>?
    <CipherReference URI=''/>?

The CipherData element envelopes or references to the raw encrypted data. If enveloping, the raw encrypted data is the CipherData element's content; if referencing, the CipherData element's URI attribute points to the location of the raw encrypted data

2.1 Encryption Granularity

Consider the following fictitious payment information, which includes identification information and information approriate to a payment method (e.g., credit card, money transfer, or electronic check):

<?xml version='1.0'?>
<PaymentInfo xmlns='http://example.org/paymentv2'>
  <Name>John Smith<Name/>
  <CreditCard Limit='5,000' Currency='USD'>
    <Number>4019 2445 0277 5567</Number>
    <Issuer>Bank of the Internet</Issuer>

This markup represents that John Smith's is using his credit card with a limit of $5,000USD.

2.1.1 Encrypting an XML Element

Smith's credit card number is sensitive information! If the application wishes to keep that information confidential, it can encrypt the CreditCard element:

<?xml version='1.0'?>
<PaymentInfo xmlns='http://example.org/paymentv2'>
  <Name>John Smith<Name/>
  <EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Element'

By encrypting the entire CreditCard element from its start to end tags, the identity of the element itself is hidden. (An evesdropper doesn't know whether he used a credit card or money transfer.) The CipherData element contains the encrypted serialization of the CreditCard element.

2.1.2 Encrypting XML Element Content (Elements)

As an alternative scenario, it may be useful for intermediate agents to know that John used a credit card with a particular limit, but not the card's number, issuer, and expiration date. In this case, the content (character data or children elements) of the CreditCard element is encrypted:

<?xml version='1.0'?> 
<PaymentInfo xmlns='http://example.org/paymentv2'>
  <Name>John Smith<Name/>
  <CreditCard Limit='5,000' Currency='USD'>
    <EncryptedData Type='http://www.w3.org/2001/04/xmlenc#Content'

2.1.3 Encrypting XML Element Content (Character Data)

Or, consider the scenario in which all the information except the actual credit card number can be in the clear, including the fact that the Number element exists:

<?xml version='1.0'?> 
<PaymentInfo xmlns='http://example.org/paymentv2'>
  <Name>John Smith<Name/>
  <CreditCard Limit='5,000' Currency='USD'>
      <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
    <Issuer>Bank of the Internet</Issuer>

Both CreditCard and Number are in the clear, but the character data content of Number is encrypted.

2.1.4 Encrypting Arbitrary Data and XML Documents

If the application scenario requires all of the information to be encrypted, the whole document is encrypted as an octet set. This applies to arbitrary data including XML documents.

<?xml version='1.0'?> 
<EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'

2.1.5 Super-Encryption: Encrypting EncryptedData

An XML document may contain zero or more EncryptedData elements. However, EncryptedData can not be the parent or child of another EncryptedData element -- though the data encrypted by this element can be anything, including EncryptedData and EncryptedKey elements (i.e., super-encryption). During super-encryption of an EncryptedData or EncryptedKey element, one must encrypt the entire element. Encrypting only the content of these elements, or encrypting selected child elements, will result in invalid XML against the schema defined in this specification.

For example, consider the following:

<pay:PaymentInfo xmlns:pay='http://example.org/paymentv2'>
  <EncryptedData ID='ED1' Type='http://www.w3.org/2001/04/xmlenc#Element'

A valid super-encryption of '//EncryptedData[@ID='ED1']' would be:

<pay:PaymentInfo xmlns:pay='http://example.org/paymentv2'>
  <EncryptedData ID='ED2' Type='http://www.w3.org/2001/04/xmlenc#Element'

where 'newEncryptedData' is the base64 encoding of the encrypted octet sequence resulting from encrypting the EncryptedData element with Id='ED1'.

2.2 EncryptedData and EncryptedKey Usage

2.2.1 EncryptedData with Symmetric Key  (KeyName)

[s1] <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
[s2]   <EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#3des-cbc '/>
[s3]   <KeyInfo>
[s4]     <ds:KeyName xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
           John Smith
[s5]   </KeyInfo>
[s6]   <CipherData>DEADBEEF</CipherData>
[s7] </EncryptedData>

[s1] The type of data encrypted may be represented as an attribute value as an aid in decryption and subsequent processing. In this case, the data encrypted was an 'Element'. Other alternatives include 'Content' of an element, or an an external octet sequence that is identified by a media type URI.

[s2] This (3DES CBC) is a symmetric key cipher.

[s4-s5] The symmetric key has the name John Smith.

[s6] CipherData will always be a base64 encoded octet sequence or a URI reference with any transforms necessary to obtain the cipher data as an octet sequence.

2.2.2 EncryptedKey (ReferenceList, KeyRetrievalMethod,CarriedKeyName)

The following EncryptedData structure is very similar to the one above, except this time the key is referenced using a KeyRetrievalMethod:

[t01] <EncryptedData Id='ED' xmlns:enc='http://www.w3.org/2001/04/xmlenc#'>
[t02]   <EncryptionMethod 
[t03]   <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
[t04]     <KeyRetrievalMethod URI='#EK'/>
[t05]     <ds:KeyName>John Doe<ds:KeyName>
[t06]   </ds:KeyInfo>
[t07]   <CipherData>DEADBEEF</CipherData>
[t08] </EncryptedData>

[t02] This (AES-128-CBC) is a symmetric key cipher.

[t03] The (AES) key is located at '#EK'.

[t04] KeyRetrievalMethod is analogous to the ds:RetrievalMethod except that the type of the referent is always of type EncryptedKey:

[t05] ds:KeyName provides an alternative method of identifying the key needed to decrypt the CipherData. Either or both the KeyName and KeyRetrivalMethod could be used to identify the key.

[t09] <EncryptedKey Id='EK' CarriedKeyName="John Doe"
[t10]  xmlns='http://www.w3.org/2001/04/xmlenc#'>
[t11]   <EncryptionMethod 
[t12]   <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
[t13]     <ds:KeyName>John Smith</ds:KeyName>
[t14]   </ds:KeyInfo>
[t15]   <CipherData>xyzabc</CipherData>
[t16]   <ReferenceList>
[t17]     <DataReference URI='#ED'/>
[t18]   </ReferenceList>
[t19] </EncryptedKey>

[t09] The EncryptedKey element is similar to the EncryptedData element except that the data encrypted is always a key value. The CarriedKeyName attribute is used to identify the encrypted key value which may be referenced by the KeyName element in KeyInfo.

[t11] The EncryptionMethod is the RSA public key algorithm.

[t13] ds:KeyName of "John Smith" is a property of the key necessary for decrypting (using RSA) the CipherData.

[t15] The CipherData is an octet sequence that is encoded (e.g., padded) by a referring encrypted object's EncryptionMethod. (Note, an EncryptedKey's EncryptionMethod is the algorithm used to encrypt these octets and does not speak about what type of octets they are.)

[t16-18] A ReferenceList identifies the encrypted objects (DataReference and KeyReference) encrypted with this key. The ReferenceList contains a list of references to data encrypted by the symmetric key carried within this structure.

3 Encryption Syntax

This section provides a detailed description of the syntax and features for XML Encryption. Features described in this section are mandatory to implement unless otherwise noted. The syntax is defined via [XML-Schema] with the following XML preamble, declaration, internal entity, and import:

  Schema Definition:

  <?xml version="1.0" encoding="utf-8"?>
  <!DOCTYPE schema  PUBLIC "-//W3C//DTD XMLSchema 200102//EN"
     <!ATTLIST schema
       xmlns:enc CDATA #FIXED 'http://www.w3.org/2001/04/xmlenc#'
       xmlns:ds CDATA #FIXED 'http://www.w3.org/2000/09/xmldsig#'>
     <!ENTITY % p ''>
     <!ENTITY % s ''>
  <schema xmlns='http://www.w3.org/2001/XMLSchema' version='0.1'

    <import namespace='http://www.w3.org/2000/09/xmldsig#'

3.1 The EncryptedType

EncryptedType is the abstract type from which EncryptedData and EncryptedKey are derived. While these two latter element types are very similar with respect to their content models, a syntactical distinction is useful to processing.

  Schema Definition:

  <complexType name='EncryptedType' abstract='true'>
      <element name='EncryptionMethod' type='ds:DigestMethodType' 
      <element ref='ds:KeyInfo' minOccurs='0'/>
      <element ref='enc:CipherData'/>
    <attribute name='Id' type='ID' use='optional'/>

EncryptionMethod is an optional element that describes the encryption algorithm applied to the CipherData contained in this element. If the element is absent, the encryption algorithm assumed to be known by the recipient.

KeyInfo is an optional element, defined by [XMLDSIG], that carries information about the key used to encrypt the CipherData. The new elements defined by this specification that may appear a children of KeyInfo are described in the subsequent sections.

CipherData is a mandatory element that provides the encrypted data.

Id is an optional attribute providing for the standard method of assigning a string id to the element within the document context.

3.2 The CipherData Element

The CipherData is a mandatory element that provides the encrypted data. It must either contain the encrypted octet sequence as base64 encoded text of the CipherValue element, or provide a reference to an external location containing the encrypted octet sequence via the CipherReference element.

The optional set of ds:DigestMethod and ds:DigestValue elements are provided for ensuring the integrity of the encrypted data. See section 5.6 of the algorithm specification for more information.

  Schema Definition:

  <element name='CipherData' type='enc:CipherDataType'/>
  <complexType name='CipherDataType'>
        <element name='CipherValue' type='ds:CryptoBinary'/>
        <element ref='enc:CipherReference'/>
      <sequence minOccurs='0'>
        <element ref='ds:DigestMethod'/> 
        <element ref='ds:DigestValue'/> 

3.2.1 The CipherReference Element

If CipherValue is not supplied directly, the CipherReference identifies a source which, when processed, yields data equivelent to the content of a CipherValue element (e.g., the base64 encoded encrypted octet sequence).

The actual value is obtained as follows. The CipherReference URI contains an identifer that is dereferenced. Should the CipherReference element contain an OPTIONAL sequence of Transforms, the data resulting from deferenced URI is transformed as specified so as to yield the intended cipher value. For example, if the value is contained in a base64 encoded XML document; the transforms could specify a base64 decoding of the XML document, followed by an XPath expression to extract the literal cipher value.

The syntax of the URI and Transforms is similar to that of [XMLDSIG] reference validation. However, there is a difference between signature and encryption processing. In [XMLDSIG] both generation and validation processing start with the same source data and perform that transform in the same order. In encryption, the decryptor has only the cipher data and the specified transforms are enumerated for the decryptor, in the order necessary to obtain the cipher value.

Consequently, in XML Encryption the specified transforms should be reversible. For instance, while an XSLT is an approriate transform in [XMLDSIG], it may not be in the encryption context because given a resulting document and the XSLT used to transform it, one can't necessarily obtain the source document. Also, note that these transforms do not affect the generation of CipherData, only its representation at the designated URI. Like [XMLDSIG], the Transforms are optional hints for resolving a information and no mandatory requirements over their processing is expressed by this specification.

For example, if the relevant cipher value is captured within an Entry element within a base64 encoded XML document, the CipherRerence might look as follows:

  <CipherReference URI="http://www.example.com/CipherValues.xml">
      <Transform Algorithm="decode"/>
          <XPath xmlns:rep="&repository;">//rep:Entry[@='3'])
  Schema Definition:

  <element name='CipherReference' type='enc:CipherReferenceType'/>
   <complexType name='CipherReferenceType'>
         <element name='Transforms' minOccurs='0'/>
       <attribute name='URI' type='anyURI' use='required'/>

     <element name="Transforms" type="ds:TransformsType"/>
     <complexType name="TransformsType">
         <element ref="ds:Transform" maxOccurs="unbounded"/> 

3.3 The EncryptedData element

The EncryptedData element is the core element in the syntax. Not only does its CipherData child contain the encrypted data, but it's also the element that replaces the encrypted element, or serves as the new document root.

  Schema Definition:

  <element name='EncryptedData' type='enc:EncryptedDataType'/>
  <complexType name='EncryptedDataType'>
      <extension base='enc:EncryptedType'>
        <attribute name='Type' type='anyURI' use='optional'/>

Type is an optional attribute identifying type information about the decrypted content.

3.4 Extensions to KeyInfo Element

There are different ways to define the key material to be used in decrypting the CipherData:

  1. The EncryptedData or EncryptedKey element specifies the associated key material:
    1. The key value may be explicitly included within an EncryptedKey element
    2. The key value may be referenced. This can be the KeyRetrievalMethod element used to indicate the URI of an EncryptedKey or a KeyName element used to indicate a key known by the recipient.
  2. The EncryptedKey element specifies the EncryptedData or EncryptedKey element which needs it:
    1. An EncryptedKey element can refer to the EncryptedData element via a DataReference element.
  3. The key material is managed at the application level, out of band of the XML Encryption specification:
    1. The key material is known to the recipient of the object by context.

This specification defines two elements that may be used as children of the ds:KeyInfo element. These are the EncryptedKey and KeyRetrievalMethod elements described in subsequent sections.

3.4.1 The EncryptedKey Element

The EncryptedKey element is used to transport encryption keys from the originator to a known recipient(s). It may be used as a standalone XML document, be placed within an application document, or appear inside an EncryptedData element as a child of a KeyInfo element. The key value is always encrypted to the recipient(s).

  Schema Definition:

  <element name='EncryptedKey' type='enc:EncryptedKeyType'/>
  <complexType name='EncryptedKeyType'>
      <extension base='enc:EncryptedType'>
          <element ref='enc:ReferenceList' minOccurs='0'/>
        <attribute name='CarriedKeyName' type='string' use='optional'/>
        <attribute name='Recipient' type='string' use='optional'/>

ReferenceList is an optional element containing pointers to data and keys encrypted using this key. The reference list may contain multiple references to EncryptedKey and EncryptedData elements. This is done using KeyReference and DataReference elements repectively. These are defined below.

CarriedKeyName is an optional attribute for associating a user readable name with the key value. This may then be used to reference the key using the ds:KeyName element within KeyInfo. The same CarriedKeyName label, unlike an ID type, may occur multiple times within a single document. The value of the key is to be the same in all EncryptedKey elements identified with the same CarriedKeyName label within a single XML document

Recipient is an optional attribute that contains a hint as to which recipient this encrypted key value is intended for. Its contents are application dependent.

3.4.2 The KeyRetrievalMethod Element

The KeyRetrievalMethod element provides a way to express a link to an EncryptedKey element containing the key needed to decrypt the CipherData associated with an EncryptedData or EncryptedKey element. The KeyRetrievalMethod is always a child of the ds:KeyInfo element and may appear multiple times. If there is more than one instance of a KeyRetievalMethod in a KeyInfo, then the EncryptedKey objects referred to must contain the same key value, possibly encrypted in different ways or for different recipients.

  Schema Definition:

   <element name='KeyRetrievalMethod' type='enc:KeyRetrievalMethodType' />
   <complexType name='KeyRetrievalMethodType'>
       <restriction base='ds:RetrievalMethodType'>
           <element name='ds:Transforms' minOccurs='0'/> 
         <attribute name='URI' type='anyURI'/>
         <attribute name='Type' type='anyURI' use='optional' 
          fixed='http://www.w3.org/2001/04/xmlenc#EncryptedKey' />

KeyRetrievalMethod uses similar syntax and dereferencing behavior to the RetrievalMethod element in [XMLDSIG], except the type attribute is always fixed to be of type EncryptedKey.

3.5 The ReferenceList Element

ReferenceList is an element that contains pointers from a key value to items encrypted by that key value (EncryptedData or EncryptedKey elements).

  Schema Definition:

  <element name='ReferenceList'>
        <element name='DataReference' type='enc:ReferenceType'
         minOccurs='0' maxOccurs='unbounded'/>
        <element name='KeyReference' type='enc:ReferenceType'
         minOccurs='0' maxOccurs='unbounded'/>

  <complexType name='ReferenceType'>
      <any namespace='##other' minOccurs='0' maxOccurs='unbounded'/>
    <attribute name='URI' type='anyURI' use='optional'/>

DataReference elements are used to refer to EncryptedData elements that were encrypted using the key defined in the enclosing EncryptedKey element. Multiple DataReference elements can occur if multiple EncryptedData elements exist that are encrypted by the same key.

KeyReference elements are used to refer to EncryptedKey objects that were encrypted using the key defined in the enclosing EncryptedKey element. Multiple KeyReference elements can occur if multiple EncryptedKey elements exist that are encrypted by the same key.

For both types of references one may optionally specify child elements to aid the recipient in retrieving the EncryptedKey and/or EncryptedData elements. These could include information such as XPath transforms, decompression transforms, or information on how to retrieve the objects from a document storage facility.

4 Processing Rules

This section describes the operations to be performed as part of encryption and decryption processing.

4.1 Encryption

For each data item or key to be encrypted:

  1. Select the algorithm (and parameters) to be used in encrypting this item.
  2. Generate or obtain the encryption key to be used.
  3. Locate the octet sequence to be encrypted.
    1. If the data to be encrypted is an [XML] element, the octet sequence is an UTF-8 encoded string representation of the element. This UTF-8 encoded octet sequence is encrypted by the key obtained in the previous step.
    2. If the data to be encrypted is [XML] element content, the octet sequence is an UTF-8 encoded string representation of the element content. This UTF-8 encoded octet sequence is encrypted by the key obtained in the previous step.
    3. If the data to be encrypted is an external octet sequence, it is encrypted by the key obtained in the previous step.
  4. Build the XML structure for this encryption step
    1. If the data being encrypted is an [XML] element or [XML] element content, the unencrypted data is removed and replaced with the new XML structure using the same encoding as its parent XML document.
    2. If the data being encrypted is an external octet sequence, create an EncryptedData structure including or referencing the encrypted data and use it as the top-level element in a new XML Document or insert it into another XML document (this is processing is application dependent).

4.2 Decryption

For each item to be decrypted (either an EncryptedData or EncryptedKey element):

  1. Parse the element to determine the algorithm, parameters and key to be used.
  2. If the data encryption key is encrypted, locate the corresponding key to decrypt it. (This may be a recursive step as the key may itself be encrypted. Or, one might retrieve the data encryption key from a local store using the provided attributes or implicit binding.)
  3. Decrypt the data contained in the required CipherData element. When the data is XML, the resulting octets are interpretated as an UTF-8 encoded string of XML characters representing an element or element content.
  4. If it is an EncryptedData structure and the type is "Element" or "ElementContent", then place the resulting characters in place of the EncryptedData element with the encoding of the parent XML document if necessary. Otherwise, the octet sequence is the final result.

4.3 XML Encryption

The specification above presumes that the data to be encrypted is processed as an octet sequence. The application is responsible for serializing the XML into an octet sequence that will be useful subsequent to decryption. For instance, if the applications wishes to canonicalize (using [XML-C14N] or some other serialization) or encode/compress the data in an XML packaging format, the application needs to marshal the XML accordingly and identify the resulting type with optional the EncryptedData Type attribute. The likelihood of interoperable decryption and subsequent use will be dependent on the decryptors support for a given type. Also, if the data is intended to be processed both before and after decryption (e.g., XML Signature [XMLDSIG] validation or XSLT transform) the encryptor must be careful to preserve information necessary for that process's success.

For interoperability purposes, the following types MUST be implemented.

Element 'http://www.w3.org/2001/04/xmlenc#Element'
"[39] element ::= EmptyElemTag | STag content ETag" [XML]
Content ' http://www.w3.org/2001/04/xmlenc#Content'
"[43] content ::= CharData? ((element | Reference | CDSect | PI | Comment) CharData?)*" [XML]
MediaType ' http://www.isi.edu/in-notes/iana/assignments/media-types/*/*'
A user specified media type (e.g., text/xml). All such types are implemented as simple octet encryption.

5 Algorithms


6 Security Considerations

6.1 Relationship to XML Digital Signatures

The application of both encryption and digital signatures over portions of an XML document can make subsequent decryption and signature verification difficult. In particular, when verifying a signature one must be know whether the signature was computed over the encrypted or unencrypted representation of elements.

A separate, but important, issue is introducing cryptographic vulnerabilities when combining digital signatures and encryption over a common XML element. Hal Finney has suggested that encrypting digitally signed data, while leaving the digital signature in the clear, may allow plaintext guessing attacks.

In accordance with the requirements document [EncReq] the interaction of encryption and signing is an application issue and out of scope of the specification. However, we make the following recommendations:

  1. When data is encrypted, any signature over that data should be encrypted. This satisfies the first issue in that only those signatures that can be seen can be validated. It also addresses the plaintext guessing vulnerability, though it may not be possible to identify (or even know of) all the signatures over a given piece of data.
  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. This specification will also need to address vulnerabilities arising from plaintext guessing attacks in a similar way.

6.2 Information Revealed

Where a symmetric key is shared amongst multiple recipients, its encapsulating EncryptedKey should not reference or be referenced by other data not intended for all of those multiple recipients. (Kind of complex...? [Shchaad supports removal])

Where a symmetric key is shared amongst multiple recipients, that symmetric key should *only* be used for the data intended for those multiple recipients. (Quite strong.)

7 Schema, DTD, Valid Examples


8 Issues

8.1 Recently Closed

  1. Moved to a CarriedKeyName attribute within EncryptedKey element.

8.2 Recently Opened

  1. Plug in algorithm section as it matures. -- Reagle.
  2. Can we move away from KeyRetrievalMethod, and just use dsig's RetrievalMethod with a particular type? -- Reagle
  3. Are the use of "reverse transforms" well specified or even necessary? -- Schaad
  4. Is the current use of Digest[Value/Method] within CipherData approriate? -- Schaad
  5. Where does the ReferenceList properly fall in EncryptedKey given its a sibling of other "inherited" elements? -- Schaad.

9 References

ANSI. Triple Data Encryption Algorithm Modes of Operation, ANSI X9.52, 1998.
Joan Daemen and Vincent Rijmen. AES Proposal: Rijndael, 2000.
Document Object Model (DOM) Level 1 Specification. W3C Recommendation. V. Apparao, S. Byrne, M. Champion, S. Isaacs, I. Jacobs, A. Le Hors, G. Nicol, J. Robie, R. Sutor, C. Wilson, L. Wood. October 1998.
Joseph Reagle. XML Encryption Requirements.
Eric Rescorla. Diffie-Hellman Key Agreement Method, RFC 2631, 1999.
RFC 2104. HMAC: Keyed-Hashing for Message Authentication. H. Krawczyk, M. Bellare, R. Canetti. February 1997.
RFC 2616. Hypertext Transfer Protocol -- HTTP/1.1. J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. June 1999.
XML Information Set, W3C Working Draft. John Cowan.
RFC 2119 Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. March 1997.
RFC 1321. The MD5 Message-Digest Algorithm. R. Rivest. April 1992.
RFC 2045. Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. N. Freed & N. Borenstein. November 1996.
XML Encryption strawman proposal. Ed Simon and Brian LaMacchia. Aug 09 2000.
Another proposal of XML Encryption. Takeshi Imamura. Aug 14 2000.
XML Encryption Syntax and Processing. Dillaway, Fox, Imamura, LaMacchia, Maruyama, Schaad, Simon. December 2000.
RFC 2437. PKCS #1: RSA Cryptography Specifications Version 2.0. B. Kaliski, J. Staddon. October 1998.
RFC 2781. UTF-16, an encoding of ISO 10646. P. Hoffman , F. Yergeau. February 2000.
RFC 2279. UTF-8, a transformation format of ISO 10646. F. Yergeau. January 1998.
RFC 2396. Uniform Resource Identifiers (URI): Generic Syntax. T. Berners-Lee, R. Fielding, L. Masinter. August 1998.
RFC 2732. Format for Literal IPv6 Addresses in URL's. R. Hinden, B. Carpenter, L. Masinter. December 1999.
RFC 1738. Uniform Resource Locators (URL). Berners-Lee, T., Masinter, L., and M. McCahill. December 1994.
RFC 2141. URN Syntax. R. Moats. May 1997.
RFC 2611. URN Namespace Definition Mechanisms. L. Daigle, D. van Gulik, R. Iannella, P. Falstrom. June 1999.
ITU-T Recommendation X.509 version 3 (1997). "Information Technology - Open Systems Interconnection - The Directory Authentication Framework"  ISO/IEC 9594-8:1997.
Extensible Markup Language (XML) 1.0. W3C Recommendation. T. Bray, J. Paoli, C. M. Sperberg-McQueen. February 1998.
Canonical XML. W3C Proposed Recommendation. J. Boyer. March 2001.



XML-Signature Syntax and Processing. Working Draft. D. Eastlake, J. Reagle, and D. Solo.
RFC 2376. XML Media Types. E. Whitehead, M. Murata. July 1998.
Namespaces in XML W3C Recommendation. T. Bray, D. Hollander, A. Layman. Janaury 1999.
XML Schema Part 1: Structures W3C Candidate Recommendation. D. Beech, M. Maloney, N. Mendelsohn. May 2001.
XML Schema Part 2: Datatypes W3C Candidate Recommendation. P. Biron, A. Malhotra. May 2001.