W3C

XML Encryption Syntax and Processing

W3C Working Draft 18 October 2001

This version:
http://www.w3.org/TR/2001/WD-xmlenc-core-20011018/
Latest version:
http://www.w3.org/TR/xmlenc-core/
Previous version:
http://www.w3.org/TR/2001/WD-xmlenc-core-20010626/
Editors
Donald Eastlake <dee3@torque.pothole.com>
Joseph Reagle <reagle@w3.org>
Authors
Takeshi Imamura <IMAMU@jp.ibm.com>
Blair Dillaway <blaird@microsoft.com>
Jim Schaad <jimsch5@home.com>
Ed Simon <edsimon@xmlsec.com>
Contributors
See participants.

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

Abstract

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 Last Call for the "XML Encryption Syntax and Processing" specification from the XML Encryption Working Group (Activity). This version specifies the Working Group's apprach to satisfying the requirements stemming from the March 2001 face-to-face meeting and subsequent discussion on the list. The last call period is 3 weeks, ending on 9 November 2001.

The Working Group will try to use a new namespace when changes in its syntax or processing are substantive. However, this namespace might be reused (prior to reaching Candidate Recommendation) by subsequent drafts in such a way as to cause instances using the namespace to become invalid or to change in meaning or affect the operation of existing software. Requests for a more stringent level of namespace stability should be made to the Working Group.

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. It is inappropriate to cite a W3C Working Draft as anything other than a "work in progress." A list of current W3C working drafts can be found at http://www.w3.org/TR/.

Please send comments to the editors (<reagle@w3.org>, <dee3@torque.pothole.com>) and cc: the list xml-encryption@w3.org (archives)

Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page in conformance with W3C policy.

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, ds:RetrievalMethod,CarriedKeyName)
  3. Encryption Syntax
    1. The EncryptedType
    2. The CipherData Element
      1. The CipherReference Element
    3. The EncryptedData element
    4. Extensions to ds:KeyInfo Element
      1. The EncryptedKey Element
      2. The ds:RetrievalMethod Element
    5. The ReferenceList Element
    6. The EncryptionProperties Element
  4. Processing Rules
    1. Encryption
    2. Decryption
    3. Encrypting XML
  5. Algorithms
    1. Algorithm Identifiers and Implementation Requirements
    2. Block Encryption Algorithms
    3. Stream Encryption Algorithms
    4. Key Transport
    5. Key Agreement
    6. Symmetric Key Wrap
    7. Message Digest
    8. Message Authentication
    9. Canonicalization
  6. Security Considerations
  7. Schema and Valid Examples
  8. 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 arbitrary data (including entire XML documents), 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:

   xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'

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

   xmlns:ds='http://www.w3.org/2000/09/xmldsig#'

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 &xenc; entity or "xenc" 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 in accordance with the contributor policies and the active WG roster.

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?>
    <EncryptionMethod/>?
    <ds:KeyInfo>
      <EncryptedKey>?
      <AgreementMethod>?
      <ds:KeyName>?
      <ds:RetrivalMethod>?
      <ds:*>?
    </ds:KeyInfo>?
    <CipherData>
      <CipherValue>?
      <CipherReference URI?>?
    </CipherData>
</EncryptedData>

The CipherData element envelopes or references the raw encrypted data. If enveloping, the raw encrypted data is the CipherValue element's content; if referencing, the CipherReference 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 appropriate 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>
    <Expiration>04/02</Expiration>
    </CreditCard>
    </PaymentInfo>

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'
     xmlns='http://www.w3.org/2001/04/xmlenc#'>
      <CipherData>
        <CipherValue>A23B45C56</CipherValue>
      </CipherData>
    </EncryptedData>
  </PaymentInfo>

By encrypting the entire CreditCard element from its start to end tags, the identity of the element itself is hidden. (An eavesdropper 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 xmlns='http://www.w3.org/2001/04/xmlenc#'
       Type='http://www.w3.org/2001/04/xmlenc#Content'>
        <CipherData>
          <CipherValue>A23B45C56</CipherValue>
        </CipherData>
      </EncryptedData>
    </CreditCard>
  </PaymentInfo>

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'>
      <Number>
        <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#'
         Type='http://www.w3.org/2001/04/xmlenc#Content'>
          <CipherData>
            <CipherValue>A23B45C56</CipherValue>
          </CipherData>
        </EncryptedData>
      </Number>
      <Issuer>Bank of the Internet</Issuer>
      <Expiration>04/02</Expiration>
    </CreditCard>
  </PaymentInfo>

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#'
   Type='http://www.isi.edu/in-notes/iana/assignments/media-types/text/xml'>
    <CipherData>
      <CipherValue>A23B45C56</CipherValue>
    </CipherData>
  </EncryptedData>

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. However, the actual data encrypted 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 is an invalid instance under the provided schema.
For example, consider the following:

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

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

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

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

[s1] The type of data encrypted may be represented as an attribute value to 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 an associated name "John Smith".

[s6] CipherData contains a CipherValue, which is a base64 encoded octet sequence. Alternately, it could contain a CipherReference, which is a URI reference along with transforms necessary to obtain the encrypted data as an octet sequence

2.2.2 EncryptedKey (ReferenceList, ds:RetrievalMethod, CarriedKeyName)

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

  [t01] <EncryptedData Id='ED'xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'>
  [t02]   <EncryptionMethod 
           Algorithm='http://www.w3.org/2001/04/xmlenc#aes128-cbc'/>
  [t03]   <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
  [t04]     <ds:RetrievalMethod URI='#EK'
             Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey">
  [t05]     <ds:KeyName>John Doe<ds:KeyName>
  [t06]   </ds:KeyInfo>
  [t07]   <CipherData><CipherValue>DEADBEEF</CipherValue></CipherData>
  [t08] </EncryptedData>

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

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

[t04] ds:RetrievalMethod is used to indicate the location of a key with type &xenc;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 same key.

Within the same XML document, there existed an EncryptedKey structure that was referenced within [t04]:

  [t09] <EncryptedKey Id='EK' CarriedKeyName="John Doe"
  [t10]  xmlns='http://www.w3.org/2001/04/xmlenc#'>
  [t11]   <EncryptionMethod 
           Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
  [t12]   <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
  [t13]     <ds:KeyName>John Smith</ds:KeyName>
  [t14]   </ds:KeyInfo>
  [t15]   <CipherData><CipherValue>xyzabc</CipherValue></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 ds: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's CipherValue 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"
   "http://www.w3.org/2001/XMLSchema.dtd"
   [
     <!ATTLIST schema
       xmlns:xenc 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'
          xmlns:ds='http://www.w3.org/2000/09/xmldsig#'
          xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'
          targetNamespace='http://www.w3.org/2001/04/xmlenc#'
          elementFormDefault='qualified'>

    <import namespace='http://www.w3.org/2000/09/xmldsig#'
            schemaLocation='http://www.w3.org/TR/2001/CR-xmldsig-core-20010419/xmldsig-core-schema.xsd'/>

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'>
    <sequence>
      <element name='EncryptionMethod' type='xenc:EncryptionMethodType' 
               minOccurs='0'/>
      <element ref='ds:KeyInfo' minOccurs='0'/>
      <element ref='xenc:CipherData'/>
      <element ref='xenc:EncryptionProperties'/>
    </sequence>
    <attribute name='Id' type='ID' use='optional'/>
    <attribute name='Type' type='anyURI' use='optional'/>
   </complexType>

EncryptionMethod is an optional element that describes the encryption algorithm applied to the cipher data. If the element is absent, the encryption algorithm is assumed to be known by the recipient.

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

CipherData is a mandatory element that contains the CipherValue or CipherReference with 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.

Type is an optional attribute identifying type information about the decrypted content. While optional, this specification takes advantage of it for mandatory processing described in Section 4.2. If the EncryptedData element contains data of Type Element or ElementContent, and replaces that data in an XML Document context, it is strongly recommended the Type attribute be provided. Without this information, the decryptor will be unable to automatically restore the XML Document to its original clear-text form.

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 Nonce attribute specifies the presence and length of a nonce value that is prepended to the CipherValue or data identified by the CipherReference. A nonce is a value (used only once) that is combined with the plaintext being encrypted in order to increase its entropy; this prevents "dictionary attacks" that encrypt "some known plaintext phrase with all possible keys so that the key for any given encrypted message containing that phrase may be obtained by lookup." [RFC2828]. Given that data is often redundant (e.g., XML) and that attackers may know the data's structure, applications are RECOMMENDED to encrypt data with high entropy, either by its own nature or by use of the Nonce attribute.

  Schema Definition:

  <element name='CipherData' type='xenc:CipherDataType'/>
  <complexType name='CipherDataType'>
     <choice>
       <element name='CipherValue' type='base64Binary'/>
       <element ref='xenc:CipherReference'/>
     </choice>
     <attribute name="Nonce" type="base64Binary" use="optional"/>
   </complexType>

3.2.1 The CipherReference Element

If CipherValue is not supplied directly, the CipherReference identifies a source which, when processed, yields the encrypted octet sequence.

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

The syntax of the URI and Transforms is similar to that of [XML-DSIG] reference validation. However, there is a difference between signature and encryption processing. In [XML-DSIG] 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 octets. Consequently, because it has different semantics Transforms is in the &xenc; namespace.

For example, if the relevant cipher value is captured within a CipherValue element within a different XML document, the CipherReference might look as follows:

  <CipherReference URI="http://www.example.com/CipherValues.xml">
    <Transforms>
      <ds:Transform 
       Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
          <ds:XPath xmlns:rep="http://www.example.org/repository">
            self::text()[parent::CipherValue[@id="example1"]]
          </ds:XPath>
      <ds:Transform>
      <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#base64"/>
    </Transforms>
  </CipherReference>

Transforms is in the xenc namespace because the sequence of transforms

  Schema Definition:

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

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

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='xenc:EncryptedDataType'/>
  <complexType name='EncryptedDataType'>
    <complexContent>
      <extension base='xenc:EncryptedType'>
     </extension>
    </complexContent>
  </complexType>

3.4 Extensions to ds:KeyInfo Element

There are three ways that the keying material needed to decrypt CipherData can be provided:

  1. The EncryptedData or EncryptedKey element specify the associated keying material via a child of ds:KeyInfo. All of the child elements of ds:KeyInfo specified in [XML-DSIG] MAY be used as qualified:
    1. Using the literal, unprotected, ds:KeyValue to transport the encryption key is obviously NOT RECOMMENDED.
    2. Support of KeyName to refer to an EncryptedKey CarriedKeyName is RECOMMENDED.
    3. Support for same document ds:RetrievalMethod is REQUIRED.

    In addition, we provide two additional child elements: applications MUST support EncryptedKey (Section 3.4.1) and MAY support AgreementMethod (Section 5.5).

  2. A detached (not inside KeyInfo) EncryptedKey element can specify the EncryptedData or EncryptedKey to which its decrypted key will apply via a DataReference or KeyReference (Section 3.5).
  3. The keying material can be determined by the recipient by application context and thus need not be explicitly mentioned in the transmitted XML.

3.4.1 The EncryptedKey Element

Identifer
Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"

(this can be used within a ds:RetrievalMethod element to identify the referent's type)

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

  Schema Definition:

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

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 respectively. 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 ds: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 ds:RetrievalMethod Element

The ds:RetrievalMethod [XML-DSIG]with a Type of 'http://www.w3.org/2001/04/xmlenc#EncryptedKey' 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 ds:RetrievalMethod with this type is always a child of the ds:KeyInfo element and may appear multiple times. If there is more than one instance of a ds:RetrievalMethod in a ds:KeyInfo of this type, then the EncryptedKey objects referred to must contain the same key value, possibly encrypted in different ways or for different recipients.

  Schema Definition:

  <!--
      <attribute name='Type' type='anyURI' use='optional'
      fixed='http://www.w3.org/2001/04/xmlenc#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'>
    <complexType>
      <sequence>
        <element name='DataReference' type='xenc:ReferenceType'
         minOccurs='0' maxOccurs='unbounded'/>
        <element name='KeyReference' type='xenc:ReferenceType'
         minOccurs='0' maxOccurs='unbounded'/>
      </sequence>
    </complexType>
  </element>

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

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. For example:

  <ReferenceList>
    <DataReference><ds:Transforms>
      <ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
        <ds:XPath xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
          self::xenc:EncryptedData[@Id="example1"]
        </ds:XPath></ds:Transforms>
      </ds:Transform>
    </DataReference>
  </ReferenceList>

3.6 The EncryptionProperties Element

Identifier
Type="http://www.w3.org/2001/04/xmlenc#EncryptionProperties"

(this can be used within a ds:Reference element to identify the referent's type)

Additional information items concerning the generation of the EncryptedData or EncryptedKey can be placed in an EncryptionProperty element (i.e., date/time stamp or the serial number of cryptographic hardware used during encryption).

  Schema Definition:

  <element name="EncryptionProperties" type="xenc:EncryptionPropertiesType"/> 
  <complexType name="EncryptionPropertiesType">
    <sequence>
      <element ref="xenc:EncryptionProperty" maxOccurs="unbounded"/> 
    </sequence>
    <attribute name="Id" type="ID" use="optional"/> 
  </complexType>

    <element name="EncryptionProperty" type="xenc:EncryptionPropertyType"/> 
    <complexType name="EncryptionPropertyType" mixed="true">
      <choice maxOccurs="unbounded">
        <any namespace="##other" processContents="lax"/
      </choice>
      <attribute name="Target" type="anyURI" use="optional"/> 
      <attribute name="Id" type="ID" use="optional"/> 
    </complexType>

4 Processing Rules

This section describes the operations to be performed as part of encryption and decryption processing by implementations of this specification. The conformance requirements are specified over the following roles:

Application
The application which makes request of an XML Encryption implementation via the provision of data and parameters necessary for its processing.
Encryptor
An XML Encryption implementation with the role of encrypting data.
Decryptor
An XML Encryption implementation with the role of decrypting data.

4.1 Encryption

For each data item to be encrypted as an EncryptedData or EncryptedKey (elements derived from EncryptedType), the encryptor must:

  1. Select the algorithm (and parameters) to be used in encrypting this data.
  2. Obtain and (optionally) represent the key.
    1. If the key is to be identified (via naming, URI, or included in a child element), construct the ds:KeyInfo as approriate (e.g., ds:KeyName, ds:KeyValue, ds:KeyRetrievalMethod, etc.)
    2. If the key itself is to be encrypted, construct an EncryptedKey element by recursively applying this encryption process. The result may then be a child of ds:KeyInfo, or it may exist elsewhere and may be identified in the preceding step.
  3.  Encrypt the data
    1. If the data is an [XML] Element or [XML] Element Content, obtain the octets by serializing the data in UTF-8 as specified in [XML]. Serialization MAY be done by the encryptor. If the encryptor does not serialize, then the application MUST.
    2. If the data is of any other type that is not already octets, the application MUST serialize it as octets. For example, the data might be a serialization of an XML Information Set, set of characters, binary image data, or a compressed XML element. Unless the decryptor will implicitly know the type (or encoding) of the encrypted data, the encryptor SHOULD specify the type value with the EncryptedData Type attribute.
    3. If present, prepend the nonce and encrypt the octets using the algorithm and key from steps 1 and 2.
  4. Build the EncryptedType (EncryptedData or EncryptedKey) structure:

    An EncryptedType structure represents all of the information previously discussed including the encryption algorithm, parameters, key, type of the encrypted data, etc.

    1. If the encrypted octet sequence obtained in Step 3 is to be stored in the CipherData element within the EncryptedData, then the encrypted octet sequence is base64 encoded and inserted as the content of a CipherValue element.
    2. If the encrypted octet sequence is to be stored externally to the EncryptedData structure, then represent the URI, and optional transforms, required for the Decryptor to retrieve the encrypted octet sequence within a CipherReference element.
  5. EncryptedData Processing
    1. If the Type of the encrypted data is Element or Element Content, then the encryptor MUST be able to return the EncryptedData element to the application. The application MAY use this as the top-level element in a new XML Document or insert it into another XML document.

      The encryptor SHOULD be able to replace the unencrypted Element or Content with the EncryptedData element. When an application requires an XML element or content to be replaced, it supplies the XML Document context in addition to identifying the element or content to be replaced. The encryptor removes the identified element or content and inserts the EncryptedData element in its place.

    2. If the Type of the encrypted data is not Element or Element Content, then the encryptor MUST always return the EncryptedData element to the application. The application MAY use this as the top-level element in a new XML Document or insert it into another XML document (which may require a re-encoding).

4.2 Decryption

For each EncryptedType derived element, (i.e., EncryptedData or EncryptedKey), to be decrypted, the decryptor must:

  1. Process the element to determine the algorithm, parameters and ds:KeyInfo element to be used. If some information is omitted, the application MUST supply it.
  2. Locate the data encryption key according to the ds:KeyInfo element, which may contain one or more children elements. These children have no implied processing order. If the data encryption key is encrypted, locate the corresponding key to decrypt it. (This may be a recursive step as the key-encryption 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 CipherData element.
    1. If a CipherValue child element is present, then the associated text value is retrieved and base64 decoded so as to obtain the encrypted octet sequence.
    2. If a CipherReference child element is present, the URI and optional transforms are used to retrieve the encrypted octet sequence.
    3. The encrypted octet sequence obtained is decrypted using the algorithm/parameters and key value already determined from Steps 1 and 2. If a nonce was prepended to the plaintext, remove it.
    4. If the cleartext octet sequence represents a key value, it is saved for use in decrypting the associated EncryptedData element(s). The decryptor MUST support passing this key value to the application for persistent storage. If it represents encrypted data then processing as described below is required.
  4. Process decrypted data of Type Element or Element Content.
    1. The cleartext octet sequence obtained in step 3 is interpreted as UTF-8 encoded character data.
    2. The decryptor MUST be able to return the value of Type and the UTF-8 encoded XML character data.
    3. The decryptor SHOULD support the ability to replace the EncryptedData element with the decrypted Element or Element Content represented by the UTF-8 encoded characters. The decryptor is NOT REQUIRED to perform validation on the serialized XML nor the result of this replacement operation. The application supplies the XML Document context and identifies the EncryptedData element being replaced.
  5. Process decrypted data of the Type is unspecified or is not Element or Element Content
    1. The cleartext octet sequence obtained in step 3 is always returned to the application for further processing along with the Type attribute value when specified.

4.3 XML Encryption

Encryption and decryption operations are transforms on octets. As noted in the preceding discussion, the encrypting application is responsible for the serialization of XML into an octet sequence, and that octets' semantics, such that the decrypted data is useful to the decrypting application.

For example, if the applications wishes to canonicalize its data or encode/compress the data in an XML packaging format, the application needs to marshal the XML accordingly and identify the resulting type, which will encoded in the optional EncryptedData Type attribute. The likelihood of successful decryption and subsequent processing will be dependent on the recipient's support for the given type. Also, if the data is intended to be processed both before and after decryption (e.g., XML Signature [XML-DSIG] validation or an XSLT transform) the encrypting application 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

This section discusses algorithms used with the XML Encryption specification. Entries contain the identifier to be used as the value of the Algorithm attribute of the EncryptionMethod element or other elements representing the role of the algorithm, a reference to the formal specification and definitions, where applicable, for the representation of keys and the results of cryptographic operations.

5.1 Algorithm Identifiers and Implementation Requirements

All algorithms listed below have implicit parameters depending on their role. For example, the data to be encrypted or decrypted, keying material, and direction of operation (encrypting or decrypting) for encryption algorithms. Any explicit additional parameters to an algorithm appear as content elements within the element. Such parameter child elements have descriptive element names, which are frequently algorithm specific, and SHOULD be in the same namespace as this XML Encryption specification, the XML Signature specification, or in an algorithm specific namespace. An example of such an explicit parameter could be a nonce (unique quantity) provided to a key agreement algorithm.

This specification defines a set of algorithms, their URIs, and requirements for implementation. Requirements are specified over implementation, not over requirements for encryption use. Furthermore, the mechanism is extensible, and alternative algorithms may be used.

Table of Algorithms

The table below lists the categories of algorithms. Within each category, a brief name, the level of implementation requirement, and an identifying URI are given.

Block Encryption
  1. REQUIRED TRIPLEDES
    http://www.w3.org/2001/04/xmlenc#tripledes-cbc
  2. REQUIRED AES-128
    http://www.w3.org/2001/04/xmlenc#aes128-cbc
  3. REQUIRED AES-256
    http://www.w3.org/2001/04/xmlenc#aes256-cbc
  4. OPTIONAL AES-192
    http://www.w3.org/2001/04/xmlenc#aes192-cbc
Stream Encryption
  1. none
    Syntax and recommendations given below to support user specified algorithms.
Key Transport
  1. REQUIRED RSA-v1.5
    http://www.w3.org/2001/04/xmlenc#rsa-1_5
  2. REQUIRED RSA-OAEP
    http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p
Key Agreement
  1. OPTIONAL Diffie-Hellman
    http://www.w3.org/2001/04/xmlenc#dh
Symmetric Key Wrap
  1. REQUIRED TRIPLEDES KeyWrap
    http://www.w3.org/2001/04/xmlenc#kw-tripledes
  2. REQUIRED AES-128 KeyWrap
    http://www.w3.org/2001/04/xmlenc#kw-aes128
  3. REQUIRED AES-256 KeyWrap
    http://www.w3.org/2001/04/xmlenc#kw-aes256
  4. OPTIONAL AES-192 KeyWrap
    http://www.w3.org/2001/04/xmlenc#kw-aes192
Message Digest
  1. REQUIRED SHA1
    http://www.w3.org/2000/09/xmldsig#sha1
  2. RECOMMENDED SHA256
    http://www.w3.org/2001/04/xmlenc#sha256
  3. OPTIONAL SHA512
    http://www.w3.org/2001/04/xmlenc#sha512
  4. OPTIONAL RIPEMD-160
    http://www.w3.org/2001/04/xmlenc#ripemd160
Message Authentication
  1. RECOMMENDED XML Digital Signature
    http://www.w3.org/TR/2001/CR-xmldsig-core-20010419/
Canonicalization
  1. OPTIONAL Canonical XML with Comments
    http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments
  2. OPTIONAL Canonical XML (omits comments)
    http://www.w3.org/TR/2001/REC-xml-c14n-20010315
Encoding
  1. REQUIRED base64
    http://www.w3.org/2000/09/xmldsig#base64

EncryptionMethod Element Schema

The schema for EncryptionMethod is as follows:

  Schema Definition:

  <complexType name="EncryptionMethodType" mixed="true">
    <sequence>
      <element name="KeySize" minOccurs="0" type="KeySizeType"/>
      <element name="DigestMethod" minOccurs="0" type="ds:DigestMethodType"/>
      <element name="OAEPparams" minOccurs="0" type="base64Binary"/>
      <any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      <!-- (0,unbounded) elements from (1,1) external namespace -->
     </sequence>
   <attribute name="Algorithm" type="anyURI" use="required"/>
  </complexType>

NOTE: Which child elements to the EncryptionMethod algorithm role are allowed or required depends on the specific value of the Algorithm attribute URI; however, the KeySize child element is always permitted. (Schema does not provide a facility for expressing conditionality of child element occurrence based on attribute value.) The presence of any child element under EncryptionMethod which is not permitted by the algorithm or the presence of a KeySize child inconsistent with the algorithm MUST be treated as an error. (All algorithm URIs specified in this document imply a key size but this is not true in general. Most popular stream cipher algorithms take variable size keys.)

5.2 Block Encryption Algorithms

Block encryption algorithms are designed for encrypting and decrypting data. Their identifiers appear as the value of the Algorithm attributes of EncryptionMethod elements that are children of EncryptedData.

Block encryption algorithms take, as implicit arguments, the data to be encrypted or decrypted, the keying material, and their direction of operation. For all of these algorithms specified below, an initialization vector (IV) is required that is encoded with the cipher text. For user specified block encryption algorithms, the IV, if any, could be specified as being with the cipher data, as an algorithm content element, or elsewhere.

The IV is encoded with the data for the algorithms below for ease of availability to the decryption code and to emphasize its association with the cipher text. Good cryptographic practice requires that a different IV be used for every encryption.

5.2.1 Triple DES

Identifier:
http://www.w3.org/2001/04/xmlenc#tripledes-cbc (REQUIRED)

ANSI X9.52 [TRIPLEDES] specifies three sequential FIPS 46-3 [DES] operations. The XML Encryption TRIPLEDES consists of a DES encrypt, a DES decrypt, and a DES encrypt used in the Cipher Block Chaining (CBC) mode with 192 bits of key and a 64 bit Initialization Vector (IV). Of the key bits, the first 64 are used in the first DES operation, the second 64 bits in the middle DES operation, and the third 64 bits in the last DES operation. (Each of these 64 bits of key contain 56 effective bits and 8 parity bits.) The resulting cipher text is prefixed by the IV. If included in XML output, it is then base64 encoded. An example TRIPLEDES EncryptionMethod is as follows:

  <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>

5.2.2 AES

Identifier:
http://www.w3.org/2001/04/xmlenc#aes128-cbc (REQUIRED)
http://www.w3.org/2001/04/xmlenc#aes192-cbc (REQUIRED)
http://www.w3.org/2001/04/xmlenc#aes256-cbc (OPTIONAL)

[AES] is used in the Cipher Block Chaining (CBC) mode with a 128 bit Initialization Vector (IV). The resulting cipher text is prefixed by the IV. If included in XML output, it is then base64 encoded. An example AES EncryptionMethod is as follows:

  <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc"/>

5.3 Stream Encryption Algorithms

Simple stream encryption algorithms generate, based on the key, a stream of bytes which are XORed with the plain text data bytes to produce the cipher text on encryption and with the cipher text bytes to produce plain text on decryption. They are normally used for the encryption of data and are specified by the value of the Algorithm attribute of the EncryptionMethod child of an EncryptedData element.

NOTE: It is critical that each simple stream encryption key (or key and initialization vector (IV) if an IV is also used) be used once only. If the same key (or key and IV) is ever used on two messages then, by XORing the two cipher texts, you can obtain the XOR of the two plain texts. This is usually very compromising.

No specific steam encryption algorithms are spercified herein but this section is included to provide general guidelines.

Stream algorithms typically use the optional KeySize explicit parameter. In cases where the key size is not apparent from the algorithm URI or key source, as in the use of key agreement methods, this parameter sets the key size. If the size of the key to be used is apparent and disagrees with the KeySize parameter, an error MUST be returned. Implementation of any stream algorithms is optional. The schema for the KeySize parameter is as follows:

  Schema Definition:

  <simpleType name='KeySizeType'>
    <restriction base="integer"/>
  </simpleType>

5.4 Key Transport

Key Transport algorithms are public key encryption algorithms especially specified for encrypting and decrypting keys. Their identifiers appear as Algorithm attributes to EncryptionMethod elements that are children of EncryptedKey. EncryptedKey is in turn the child of a KeyInfo element. The type of key being transported is given by the Algorithm attribute of the EncryptionMethod child of the EncryptedKey parent of this KeyInfo element. This attribute value must be the URI of an encryption algorithm.

Key Transport algorithms may optionally be used to encrypt data in which case the KeyInfo of which they are a grandchild is the child of an EncryptedData element. Because they use public key algorithms, Key Transport algorithms are not efficient for the transport of any amounts of data significantly larger than symmetric keys.

The Key Transport algorithms given below are those used in conjunction with the Cryptographic Message Syntax (CMS) of S/MIME [CMS-Algorithms, CMS-AES].

5.4.1 RSA Version 1.5

Identifier:
http://www.w3.org/2001/04/xmlenc#rsa-1_5 (REQUIRED)

The RSAES-PKCS1-v1_5 algorithm, specified in RFC 2437 [PKCS1], takes no explicit parameters. An example of an RSA Version 1.5 EncryptionMethod element is:

  <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>

The CipherValue for such an encrypted key is the base64 [MIME] encoding of the octet string computed as per RFC 2437 [PKCS1, section 7.2.1: Encryption operation]. As specified in the EME-PKCS1-v1_5 function RFC 2437 [PKCS1, section 9.1.2.1], the value input to the key transport function is as follows:

   CRYPT ( PAD ( KEY ))

where the padding is of the following special form:

   02 | PS* | 00 | key

where "|" is concatenation, "02" and "00" are fixed octets of the corresponding hexadecimal value, PS is a string of strong pseudo-random octets [RANDOM] at least eight octets long, containing no zero octets, and long enough that the value of the quantity being CRYPTed is one octet shorter than the RSA modulus, and "key" is the key being transported. The key is 168 bits for TRIPLEDES and 128, 192, or 256 bits for AES. Support of this key transport algorithm for transporting 168 bit keys is mandatory to implement. Support of this algorithm for transporting other keys is optional. RAS-OAEP is recommended for the transport of AES keys.

The resulting base64 [MIME] string is the value of the child text node of the CipherData element, e.g.

  <CipherData> IWijxQjUrcXBYoCei4QxjWo9Kg8D3p9tlWoT4
     t0/gyTE96639In0FZFY2/rvP+/bMJ01EArmKZsR5VW3rwoPxw=
  </CipherData>

5.4.2 RSA-OAEP

Identifier:
http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p (REQUIRED)

THE RSAES-OAEP-ENCRYPT, as specified in RFC 2437 [PKCS1], algorithm takes as explicit parameters a message digest function and an optional octet string OAEPparams. The message digest function is indicated by the Algorithm attribute of a child DigestMethod element and the octet string is the base64 decoding of the content of an optional OAEPparams child element. An example of an RSA-OAEP element is:

  <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
     <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
     <OAEPparams> 9lWu3Q== </OAEPparams>
  <EncryptionMethod>

The CipherData for an RSA-OAEP encrypted key is the base64 [MIME] encoding of the octet string computed as per RFC 2437 [PKCS1, section 7.1.1: Encryption operation]. As described in the EME-OAEP-ENCODE function RFC 2437 [PKCS1, section 9.1.1.1], the value input to the key transport function is calculated use the message digest function and string specified in the DigestMethod and OAEPparams elements and using the mask generator function MGF1 specified in RFC 2437. The desired output length for EME-OAEP-ENCODE is one byte shorter than the RSA modulus.

The transported key size is 168 bits for TRIPLEDES and 128, 192, or 256 bits for AES. Implementations MUST implement RSA-OAEP for the transport of 128 and 256 bit keys. They MAY implement RSA-OAEP for the transport of other keys.

5.5 Key Agreement

A Key Agreement algorithm provides for the agreement to a shared secret quantity based on certain types of compatible public keys from both the sender and the recipient. Information to determine the key associated with the originator is indicated by an optional OriginatorKeyInfo parameter child of an AgreementMethod element while that associated with the recipient is indicated by an optional RecipientKeyInfo. A shared key is derived from this shared secret by a method determined by the Key Agreement algorithm.

The AgreementMethod element appears as the content of a ds:KeyInfo since, like other ds:KeyInfo children, it yields a key. This ds:KeyInfo is in turn a child of an EncryptedData or EncryptedKey element. The Algorithm attribute and KeySize child of the EncryptionMethod element under this EncryptedData or EncryptedKey element are implicit parameters to the key agreement computation. In cases where this EncryptionMethod algorithm URI is insufficient to determine the key length, a KeySize MUST have been included. In addition, the sender may place a Nonce element under AgreementMethod to assure that different keying material is generated even for repeated agreements using the same sender and recipient public keys. For example:

  <EncryptedData>
     <EncryptionMethod Algorithm="Example:Block/Algorithm"
        <KeySize>80</KeySize>
     </EncryptionMethod>
     <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <AgreementMethod Algorithm="Example:Agreement/Algorithm">
           <Nonce> Zm9v </Nonce>
           <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256">
           <OriginatorKeyInfo>
              <KeyValue>...originator...</KeyValue>
           </OriginatorKeyInfo>
           <RecipientKeyInfo>
              <KeyValue>...recipient...</KeyValue>
           </RecipientKeyInfo>
        </AgreementMethod>
     </ds:KeyInfo>
     <CipherData>...</CipherData>
  </EncryptedData>

If the agreed key is being used to wrap a key, rather than data as above, then AgreementMethod would appear inside a ds:KeyInfo inside an EncryptedKey element.

The Schema for AgreementMethod is as follows:

  Schema Definition:

  <element name="AgreementMethod" type="xenc:AgreementMethodType"/>
  <complexType name="AgreementMethodType" mixed="true">
    <sequence>
      <element name="Nonce" minOccurs="0" type="base64Binary"/>
      <element name="DigestMethod" minOccurs="0" type="ds:DigestMethodType">
      <element name="OriginatorKeyInfo" minOccurs="0" type="ds:KeyInfoType">
      <element name="RecipientKeyInfo" minOccurs="0" type="ds:KeyInfoType">
      <any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
      <!-- (0,unbounded) elements from (1,1) external namespace -->
     </sequence>
   <attribute name="Algorithm" type="anyURI" use="required"/>
   </complexType>

5.5.1 Diffie-Hellman Key Values

Identifier:
http://www.w3.org/2001/04/xmlenc#DHKeyValue (OPTIONAL)

Diffie-Hellman keys can appear directly within KeyValue elements or be obtained by ds:RetrievalMethod fetches as well as appearing in certificates and the like. The above identifier can be used as the value of the Type attribute of Reference or ds:RetrievalMethod elements.

A DH public key consists of three quantities, a large Prime p, a "Generator" g, and "Public" such that Public = g**x mod p. The corresponding private key is x. Because a Prime and Generator can be safely shared over many DH keys, they may be known from the application environment and are optional. The schema for a DHKeyValue is as follows:

   Schema:

  <element name="DHKeyValue" type="xenc:DHKeyValueType"/>
  <complexType name="DHKeyValueType">
     <sequence>
        <element name="Prime" type="ds:CryptoBinary" minOccurs="0"/>
        <element name="Generator" type="ds:CryptoBinary" minOccurs="0"/>
        <element name="Public" type="ds:CryptoBinary"/>
     </sequence>
  </complexType>

5.5.2 Diffie-Hellman Key Agreement

Identifier:
http://www.w3.org/2001/04/xmlenc#dh (OPTIONAL)

The Diffie-Hellman (DH) key agreement protocol [ESDH] involves the derivation of shared secret information based on compatible DH keys from the sender and recipient. Two DH public keys are compatible if they have the same prime and generator. If, for the second one, Y = g**y mod p, then the two parties can calculate the shared secret ZZ = ( g**(x*y) mod p ) even though each knows only their own private key and the other party's public key. Leading zero bytes MUST be maintained in ZZ so it will be the same length, in bytes, as p. We require that p be at least 512 bits and g at least 160 bits. There are numerous other complex security considerations in the selection of g, p, and a random x as described in [ESDH].

Diffie-Hellman key agreement is optional to implement. An example of a DH AgreementMethod element is as follows:

  <xenc:AgreementMethod xenc:Algorithm="http://www.w3.org/2001/04/xmlenc#dh"
                       xmlns="http://www.w3.org/2000/09/xmldsig#">
   <xenc:Nonce>Zm9v</Nonce>
   <DigestMethod Algorith="http://www.w3.org/2000/09/xmldsig#sha1"/>
   <xenc:OriginatorKeyInfo>
        <X509Data><X509Certificate>
            ...
        </X509Certificate></X509Data>
   </OriginatorKeyInfo>
   <xenc:RecipientKeyInfo><KeyValue>
        ...
   </KeyValue></RecipientKeyInfo>
   </xenc:AgreementMethod>

(Add example with real "bits"...)

Assume the Diffie-Hellman shared secret is the octet sequence ZZ. The shared keying material needed will then be calculated as follows:

   Keying Material = KM(1) | KM(2) | ...

where "|" is byte stream concatenation and

   KM(counter) = DigestAlg ( EncryptionAlg | ZZ | counter | Nonce | KeySize ).

DigestAlg
The message digest algorithm specified by the DigestMethod child of AgreementMethod.
EncryptionAlg
The URI of the encryption algorithm, including possible key wrap algorithms, in which the derived keying material is to be used ("Example:Block/Algorithm" in the example above), not the URI of the agreement algorithm. This is the value of the Algorithm attribute of the EncryptionMethod child of the EncryptedData or EncryptedKey grandparent of AgreementMethod.
Nonce
The base64 decoding the content of the Nonce child of AgreementMethod, if present. If the Nonce element is absent, it is null.
Counter
A one byte counter starting at one and counting by one. It is expressed as two hex digits.
KeySize
The size in bits of the key to be derived from the shared secret as the UTF-8 string for the corresponding decimal integer with only digits in the string and no leading zeros. For some algorithms the key size is inherent in the URI. For others, such as most stream ciphers, it must be explicitly provided.

For example, the initial (KM(1)) calculation for the example above where the binary 1 counter byte is represented as the two character UTF-8 sequence "01", would be calculated as follows:

   SHA-256 (Example:Block/AlgorithmZZ01foo40 )

where ZZ is the binary shared secret octet sequence and "foo" is the b ase64 decoding of "Zm9v".

(Actual digest value and agreed key to be added...)

Each application of DigestAlg for successive values of Counter will produces some additional number of bytes of keying material. From the concatenated string of one or more KM's, enough leading bytes are taken to meet the need for an actual key and the remainder discarded. For example, if DigestAlg is SHA1 which produces 20 octets of hash, then for 128 bit AES the first 16 bytes from KM(1) would be taken and the remaining 4 bytes discarded. For 256 bit AES, all of KM(1) suffixed with the first 12 bytes of KM(2) would be taken and the remaining 8 bytes of KM(2) discarded.

5.6 Symmetric Key Wrap

Symmetric Key Wrap algorithms are shared secret key encryption algorithms especially specified for encrypting and decrypting symmetric keys. Their identifiers appear as Algorithm attributes to EncryptionMethod elements that are children of EncryptedKey which is in turn a child of KeyInfo which is in turn a child of EncryptedData or another EncryptedKey. The type of the key being wrapped is indicated by the Algorithm attribute of EncryptionMethod child of the parent of the KeyInfo grandparent of the EncryptionMethod specifying the symmetric key wrap algorithm.

5.6.1 CMS Key Checksum

Some key wrap algorithms make use of the Key Checksum defined in CMS [CMS-Algorithms]. This is used to provide an integrity check value for the key being wrapped. The algorithm is

  1. Compute the 20 octet SHA-1 hash on the key being wrapped.
  2. Use the first 8 octets of this hash as the checksum value.

5.6.2 CMS Triple DES Key Wrap

Identifiers and Requirements:
http://www.w3.org/2001/04/xmlenc#kw-tripledes (REQUIRED)

XML Encryption implementations MUST support TRIPLEDES wrapping of 168 bit keys and may optionally support TRIPLEDES wrapping of other keys.

An example of a TRIPLEDES Key Wrap EncryptionMethod element is a as follows:

  <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-tripledes"/>

The following algorithm wraps (encrypts) a key (the wrapped key, WK) under a TRIPLEDES key-encryption-key (KEK) as specified in [CMS-Algorithms]:

  1. Represent the key being wrapped as an octet sequence. If it is a TRIPLEDES key, this is 24 octets (192 bits) with odd parity bit as the bottom bit of each octet.
  2. Compute the CMS Key Checksum, (section 5.6.1), call this CKS.
  3. Let WKCKS = WK || CKS where || is concatenation.
  4. Generate 8 random octets [RANDOM] and call this IV.
  5. Encrypt WKCKS in CBC mode using KEK as the key and IV as the initialization vector. Call the results TEMP1.
  6. Left TEMP2 = IV || TEMP1.
  7. Reverse the order of the octets in TEMP2 and call the result TEMP3.
  8. Encrypt TEMP3 in CBC mode using the KEK and an initialization vector of 0x4adda22c79e82105. The resulting cipher text is the desired result. It is 40 octets long if a 168 bit key is being wrapped.

The following algorithm unwraps (decrypts) a key as specified in [CMS-Algorithms]:

  1. Check if the length of the cipher text is reasonable given the key type. It must be 40 bytes for a 168 bit key and either 32, 40, or 48 bytes for a 128, 192, or 256 bit key. If the length is not supported or inconsistent with the algorithm for which the key is intended, return error.
  2. Decrypt the cipher text with TRIPLEDES in CBC mode using the KEK and an initialization vector (IV) of 0x4adda22c79e82105. Call the output TEMP3.
  3. Reverse the order of the octets in TEMP3 and call the result TEMP2.
  4. Decompose TEMP2 into IV, the first 8 octets, and TEMP1, the remaining octets.
  5. Decrypt TEMP1 using TRIPLEDES in CBC mode using the KEK and the IV found in the previous step. Call the result WKCKS.
  6. Decompose WKCKS. CKS is the last 8 octets and WK, the wrapped key, are those octets before the CKS.
  7. Calculate a CMS Key Checksum, (section 5.6.1), over the WK and compare with the CKS extracted in the above step. If they are not equal, return error.
  8. WK is the wrapped key, now extracted for use in data decryption.

5.6.3 AES KeyWrap

Identifiers and Requirements:
http://www.w3.org/2001/04/xmlenc#kw-aes128 (REQUIRED)
http://www.w3.org/2001/04/xmlenc#kw-aes192 (REQUIRED)
http://www.w3.org/2001/04/xmlenc#kw-aes256 (OPTIONAL)

Implementation of AES key wrap as specified by NIST/NSA/CMS will be mandatory for AES 128 and AES 256 and optional for AES 192 -- when it has been completely specified by them.

5.7 Message Digest

Message digest algorithms can be used in CipherData to insure integrity, in AgreementMethod as part of the key derivation, within RSA-OAEP encryption as a hash function, and in connection with the HMAC Message Authentication Code method as described in [XML-DSIG].)

5.7.1 SHA1

Identifier:
http://www.w3.org/2000/09/xmldsig#sha1 (REQUIRED)

The SHA-1 algorithm [SHA] takes no explicit parameters. XML encryption implementations MUST implement SHA-1. An example of an SHA-1 DigestMethod element is:

   <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>

A SHA-1 digest is a 160-bit string. The content of the DigestValue element shall be the base64 encoding of this bit string viewed as a 20-octet octet stream. For example, the DigestValue element for the message digest:

   A9993E36 4706816A BA3E2571 7850C26C 9CD0D89D

from Appendix A of the SHA-1 standard would be:

   <DigestValue>qZk+NkcGgWq6PiVxeFDCbJzQ2J0=</DigestValue>

5.7.2 SHA256

Identifier:
http://www.w3.org/2001/04/xmlenc#sha256 (RECOMMENDED)

The SHA-256 algorithm [SHA] takes no explicit parameters. It is RECOMMENDED that XML encryption implementations implement SHA-256. An example of an SHA-256 DigestMethod element is:

   <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha256"/>

A SHA-256 digest is a 256-bit string. The content of the DigestValue element shall be the base64 encoding of this bit string viewed as a 32-octet octet stream.

5.7.3 SHA512

Identifier:
http://www.w3.org/2001/04/xmlenc#sha512 (OPTIONAL)

The SHA-512 algorithm [SHA] takes no explicit parameters. An example of an SHA-512 DigestMethod element is:

   <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha512"/>

A SHA-512 digest is a 512-bit string. The content of the DigestValue element shall be the base64 encoding of this bit string viewed as a 64-octet octet stream.

5.7.4 RIPEMD-160

Identifier:
http://www.w3.org/2001/04/xmlenc#ripemd160 (OPTIONAL)

The RIPEMD-160 algorithm [RIPEMD-160] takes no explicit parameters. An example of an RIPEMD-160 DigestMethod element is:

   <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#ripemd160"/>

A RIPEMD-160 digest is a 160-bit string. The content of the DigestValue element shall be the base64 encoding of this bit string viewed as a 20-octet octet stream.

5.8 Message Authentication

Identifier:
http://www.w3.org/2000/09/xmldsig# (RECOMMENDED)

XML Signature [XML-DSIG] is optional to implement for XML encryption applications. It is the recommended way to provide key based authentication.

5.9 Canonicalization

Identifiers and Requirements:
http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments (OPTIONAL)
http://www.w3.org/TR/2001/REC-xml-c14n-20010315 (OPTIONAL)

Canonical XML [Canon] is the recommended method of consistently serializing XML into an octet stream. If XML is to be later decrypted into a different environment and it is desired to preserve such aspects of its original environment as namespace prefix bindings, the value of attributes in the "xml" namespace, etc., then the Canonical XML With Comments version of the XML should be the serialization that is encrypted

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 know whether the signature was computed over the encrypted or unencrypted form 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. This vulnerability can be mitigated by using secure hashes and nonces in the text being processed.

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 digest or 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 possibility of a 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 [XML-DSIG-Decrypt]. 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.

Additionally, while the following warnings pertain to incorrect inferences by the user about the authenticity of information encrypted, applications should discourage user misapprension by communicating clearly which information has integrity, or is authenticated, confidential, or non-repudiable when multiple processes (e.g., signature and encryption) and algorithms (e.g., symmetric and asymmetric) are used:

  1. When an encrypted envelope contains a signature, the signature does not necessarily protect the authenticity or integrity of the ciphertext [Davis] .
  2. While the signature secures plaintext it only covers that which is signed, recipients of encrypted messages must not infer integrity or authenticity of other unsigned information (e.g., headers) within the encrypted envelope, see [XML-DSIG, 8.1.1 Only What is Signed is Secure].

6.2 Information Revealed

Where a symmetric key is shared amongst multiple recipients, that symmetric key should only be used for the data intended for all recipients; even if one recipient is not directed to information intended (exclusively) for another in the same symmetric key, the information might be discovered and decrypted.

Additionally, application designers should be careful not to reveal any information in parameters or algorithm identifiers (e.g., information in a URI) that weakens the encryption.

7 Schema and Valid Examples

Schema
xenc-schema.xsd
Example
enc-example.xml

8 References

TRIPLEDES
Triple Data Encryption Algorithm Modes of Operation, ANSI X9.52, 1998.
AES
AES Proposal: Rijndael. Joan Daemen and Vincent Rijmen. 2000.
CMS-AES
Use of the Advanced Encryption Algorithm in CMS. Internet-Draft. J. Schaad, R. Housley. July 2001.

http://www.ietf.org/internet-drafts/draft-ietf-smime-aes-alg-02.txt

CMS-Algorithms
Cryptographic Message Syntax (CMS) Algorithms. Internet-Draft. R. Housley. September 2001.
http://www.ietf.org/internet-drafts/draft-ietf-smime-cmsalg-06.txt
CMS-Wrap
Triple-DES and RC2 Key Wrapping. Internet Draft. R. Housely. September 2001.
http://www.ietf.org/internet-drafts/draft-ietf-smime-key-wrap-01.txt
Davis
Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML. D. Davis. USENIX Annual Technical Conference. 2001.
DES
NIST FIPS 46-3:Data Encryption Standard. October 1999.
DOM
Document Object Model (DOM) Level 1 Specification. 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.
http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/
EncReq
XML Encryption Requirements. Working Draft. J. Reagle. April 2001.

http://www.w3.org/TR/2001/WD-xml-encryption-req-20010420

ESDH
RFC 2631: Diffie-Hellman Key Agreement Method. Standards Track. E. Rescorla. 1999.
HMAC
RFC 2104: HMAC: Keyed-Hashing for Message Authentication. Informational. H. Krawczyk, M. Bellare, R. Canetti. February 1997.H. Krawczyk, M. Bellare, R. Canetti. February 1997.
http://www.ietf.org/rfc/rfc2104.txt
HTTP
RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1. Standards Track. J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. June 1999.J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. June 1999.
http://www.ietf.org/rfc/rfc2616.txt
InfoSet
XML Information Set. Proposed Recommendation. John Cowan.

http://www.w3.org/TR/2001/PR-xml-infoset-20010810

KEYWORDS
RFC 2119: Key words for use in RFCs to Indicate Requirement Levels. Best Current Practice. S. Bradner. March 1997.S. Bradner. March 1997.
http://www.ietf.org/rfc/rfc2119.txt
MD5
RFC 1321: The MD5 Message-Digest Algorithm. Informational. R. Rivest. April 1992.R. Rivest. April 1992.
http://www.ietf.org/rfc/rfc1321.txt
MIME
RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. Standards Track. N. Freed & N. Borenstein. November 1996.
http://www.ietf.org/rfc/rfc2045.txt
prop1
XML Encryption strawman proposal. E. Simon and B. LaMacchia. Aug 09 2000.
prop2
Another proposal of XML Encryption. T.i Imamura. Aug 14 2000.
prop3
XML Encryption Syntax and Processing . B. Dillaway, B. Fox, T. Imamura, B. LaMacchia, H. Maruyama, J. Schaad, E. Simon. December 2000.
PKCS1
RFC 2437: PKCS #1: RSA Cryptography Specifications Version 2.0. Informational. B. Kaliski, J. Staddon. October 1998.
http://www.ietf.org/rfc/rfc2437.txt
RANDOM
RFC 1750: Randomness Recommendations for Security. Informational. D. Eastlake, S. Crocker, J. Schiller. December 1994.
http://www.ietf.org/rfc/rfc1750.txt
RIPEMD-160
CryptoBytes, Volume 3, Number 2. The Cryptographic Hash Function RIPEMD-160. RSA Laboratories. Autumn 1997.
SHA
Secure Hash Standard. NIST FIPS 180-1. April 1995.
(Being extended to cover SHA-256 and SHA-512. See Draft FIPS 180-2.)
UTF-16
RFC 2781: UTF-16, an encoding of ISO 10646. Informational. P. Hoffman , F. Yergeau. February 2000.
http://www.ietf.org/rfc/rfc2781.txt
UTF-8
RFC 2279: UTF-8, a transformation format of ISO 10646F. Standards Track. Yergeau. January 1998.
http://www.ietf.org/rfc/rfc2279.txt
URI
RFC 2396: Uniform Resource Identifiers (URI): Generic Syntax. Standards Track. T. Berners-Lee, R. Fielding, L. Masinter. August 1998.
http://www.ietf.org/rfc/rfc2396.txt
URI-Literal
RFC 2732: Format for Literal IPv6 Addresses in URL's. Standards Track. R. Hinden, B. Carpenter, L. Masinter. December 1999.
http://www.ietf.org/rfc/rfc2732.txt
URL
RFC 1738: Uniform Resource Locators (URL). Standards Track. T. Berners-Lee, L. Masinter, and M. McCahill. December 1994.
http://www.ietf.org/rfc/rfc1738.txt
URN
RFC 2141: URN Syntax. Standards Track. R. Moats. May 1997.
http://www.ietf.org/rfc/rfc2141.txt
RFC 2611: URN Namespace Definition Mechanisms. Best Current Practices. Daigle, D. van Gulik, R. Iannella, P. Falstrom. June 1999.
http://www.ietf.org/rfc/rfc2611.txt
X509v3
ITU-T Recommendation X.509 version 3 (1997). "Information Technology - Open Systems Interconnection - The Directory Authentication Framework"  ISO/IEC 9594-8:1997.
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. Recommendation. J. Boyer. March 2001.
http://www.w3.org/TR/2001/REC-xml-c14n-20010315
http://www.ietf.org/rfc/rfc3076.txt
XML-DSIG
XML-Signature Syntax and Processing. Proposed Recommendation. D. Eastlake, J. Reagle, and D. Solo.
http://www.w3.org/TR/2001/PR-xmldsig-core-20010820/
XML-DSIG-Decrypt
Decryption Transform for XML Signature. Working Draft. T. Imamura and H. Maruyama.
http://www.w3.org/TR/2001/WD-xmlenc-decrypt-20010626
XML-MT
RFC 2376: XML Media Types. Informational. E. Whitehead, M. Murata. July 1998.
http://www.ietf.org/rfc/rfc2376.txt
XML-NS
Namespaces in XML. Recommendation. T. Bray, D. Hollander, A. Layman. Janaury 1999.
http://www.w3.org/TR/1999/REC-xml-names-19990114
XML-schema
XML Schema Part 1: Structures Recommendation. D. Beech, M. Maloney, N. Mendelsohn. May 2001.
http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/
XML Schema Part 2: Datatypes Recommendation. P. Biron, A. Malhotra. May 2001.
http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/