XML Encryption Syntax and Processing

WG Working Draft 26 June 2001

This version:: http://www.w3.org/TR/2001/WD-xmlenc-core-20010626/
Latest version:: http://www.w3.org/TR/xmlenc-core/
Previous version:: This draft is based on the 15-December-2000 Proposal [prop3] by Dillaway, Fox, Imamura, LaMacchia, Maruyama, Schaad, and Simon.
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.

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 the first draft of the "XML Encryption Syntax and Processing" specification from the XML Encryption Working Group (Activity).This version attempts to capture the consensus resulting from the 01 March 2001 face-to-face meeting and subsequent discussion on the list. However, it does contain points which are still under discussion or not well specified.

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.

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:

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

Additionally, this specification makes use of the XML Signature [XMLDSIG] 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 &enc; entity or "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: See partipants. [These names will placed within this document when it has reached a sufficient maturity.]

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/>?
   <ds:*/>?
  </ds:KeyInfo>?
  <CipherData>
    <CipherValue>(encrypted character data)</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 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>
    <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 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'
     xmlns='http://www.w3.org/2001/04/xmlenc#'>
      <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' Type='http://www.w3.org/2001/04/xmlenc#Element'
   xmlns='http://www.w3.org/2001/04/xmlenc#'>
    <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' Type='http://www.w3.org/2001/04/xmlenc#Element'
   xmlns='http://www.w3.org/2001/04/xmlenc#'>
    <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 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's either contains a CipherValue which must ~~will~~ always be a base64 encoded octet sequence or a CipherReference URI reference with any transforms necessary to obtain the cipher 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:enc='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 enc: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 
         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: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'
          xmlns:ds='http://www.w3.org/2000/09/xmldsig#'
          xmlns:enc='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='enc:EncryptionMethodType' 
               minOccurs='0'/>
      <element ref='ds:KeyInfo' minOccurs='0'/>
      <element ref='enc:CipherData'/>
    </sequence>
    <attribute name='Id' type='ID' 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 [XMLDSIG], 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.

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'>
    <sequence>
      <choice>
        <element name='CipherValue' type='ds:CryptoBinary'/>
        <element ref='enc:CipherReference'/>
      </choice>
      <sequence minOccurs='0'>
        <element ref='ds:DigestMethod'/> 
        <element ref='ds:DigestValue'/> 
      </sequence>
     </sequence>
   </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 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 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 [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 octets.

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

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

  Schema Definition:

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


     <element name="Transforms" type="ds:TransformsType"/>
     <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='enc:EncryptedDataType'/>
  <complexType name='EncryptedDataType'>
    <complexContent>
      <extension base='enc:EncryptedType'>
        <attribute name='Type' type='anyURI' use='optional'/>
      </extension>
    </complexContent>
  </complexType>

Type is an optional attribute identifying type information about the decrypted content. This type information plays a key role in the behavior of compliant decryptors as decribed 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.4 Extensions to `ds:KeyInfo` Element

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

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 ds:RetrievalMethod element used to indicate the URI of an EncryptedKey or a KeyName element used to indicate a key known by the recipient.
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.
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 the EncryptedKey element and uses the ds:RetrievalMethod element as 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 ds:KeyInfo element. The key value is always encrypted to the recipient(s).

  Schema Definition:

  <element name='EncryptedKey' type='enc:EncryptedKeyType'/>
  <complexType name='EncryptedKeyType'>
    <complexContent>
      <extension base='enc:EncryptedType'>
        <sequence>
          <element ref='enc: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 [XMLDSIG] 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. It always refers to an EncryptedKey and it's Type is always 'http://www.w3.org/2001/04/xmlenc#EncryptedKey'. 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, 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='enc:ReferenceType'
         minOccurs='0' maxOccurs='unbounded'/>
        <element name='KeyReference' type='enc: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='optional'/>
  </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.

An example using an XPath transform might be:

<ReferenceList>
	<DataReference>
		<Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116"> 
			<XPath> self::text()[parent::CipherValue[@id="example1"]] </XPath>
		</Transform>
  	</DataReference>
</ReferenceList>

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:

Select the algorithm (and parameters) to be used in encrypting this item.
Generate or obtain the encryption key to be used.
Locate the octet sequence to be encrypted.
1. If the data to be encrypted is an [XML] element or [XML] element content, the octet sequence is an UTF-8 encoded string representation of the element or its content respectively. This UTF-8 encoded octet sequence is encrypted by the key obtained in the previous step.
  Encryption applications are recommended to use the optional Type attribute of EncryptedData with the approriate value so as to allow automated document restoration processing as described in Section 4.2.
2. If the data to be encrypted is an external octet sequence, it is encrypted by the key obtained in the previous step.
Encryption applications are recommended to use the optional Type attribute of EncryptedData with the approriate value so as to allow automated document restoration processing as described in Section 4.2.
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):

Parse the element to determine the algorithm, parameters and key to be used.
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.)
Decrypt the data contained in the required CipherData element. When the data is XML, the resulting octets are interpreted as an UTF-8 encoded string of XML characters representing an element or element content.
1. If CipherData contains a CipherValue element, obtain the octet stream by de-base64ing its content.
2. If CipherData contains a CipherReference element, dereference the value of the URI attribute and apply the specified transforms (if any) to obtain the octet stream.
If it is an EncryptedData structure and the Type is "Element" or "Content", 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

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, alternative algorithms may be used by encryption applications.

Table of Algorithms

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

Block Encryption

REQUIRED 3DES
http://www.w3.org/2001/04/xmlenc#des3-cbc
REQUIRED AES-128
http://www.w3.org/2001/04/xmlenc#aes128-cbc
REQUIRED AES-256
http://www.w3.org/2001/04/xmlenc#aes256-cbc
OPTIONAL AES-192
http://www.w3.org/2001/04/xmlenc#aes192-cbc

Stream Encryption

OPTIONAL ARCFOUR
http://www.w3.org/2001/04/xmlenc#arcfour

Key Transport

REQUIRED RSA-v1.5
http://www.w3.org/2001/04/xmlenc#rsa-1_5
REQUIRED RSA-OAEP
http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p

Key Agreement

OPTIONAL Diffie-Hellman
http://www.w3.org/2001/04/xmlenc#dh

Symmetric Key Wrap

REQUIRED 3DES KeyWrap
http://www.w3.org/2001/04/xmlenc#kw-3des
REQUIRED AES-128 KeyWrap
http://www.w3.org/2001/04/xmlenc#kw-aes128
REQUIRED AES-256 KeyWrap
http://www.w3.org/2001/04/xmlenc#kw-aes256
OPTIONAL AES-192 KeyWrap
http://www.w3.org/2001/04/xmlenc#kw-aes192

Message Digest

REQUIRED SHA1
http://www.w3.org/2000/09/xmldsig#sha1
RECOMMENDED SHA256
http://www.w3.org/2001/04/xmlenc#sha256
OPTIONAL SHA512
http://www.w3.org/2001/04/xmlenc#sha512
OPTIONAL RIPEMD-160
http://www.w3.org/2001/04/xmlenc#ripemd160

Message Authentication

RECOMMENDED XML Digital Signature
http://www.w3.org/TR/2001/CR-xmldsig-core-20010419/

Canonicalization

RECOMMENDED Canonical XML with Comments
http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments
OPTIONAL Canonical XML (omits comments)
http://www.w3.org/TR/2001/REC-xml-c14n-20010315

Encoding

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="OAEPparamsType"/>
       <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. (Schema does not provide a facility for expressing conditionality of child element occurrance based on attribute value.) The presence of any child element under EncryptionMethod which is not permitted by the algorithm MUST be treated as an error.

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 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 element content, 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

Identifiers:: http://www.w3.org/2001/04/xmlenc#des3-cbc

The triple DES algorithm is described in FIPS 46-3 [DES] and ANSI X9.52 [3DES]. It is composed of three sequential DES operations. The XML Encryption 3DES 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 before being encoded in base64 for inclusion in XML output. Encryption applications MUST implement 3DES for data encryption. An example 3DES EncryptionMethod is as follows:

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

5.2.2 AES

Identifiers:: http://www.w3.org/2001/04/xmlenc#aes128-cbc; http://www.w3.org/2001/04/xmlenc#aes192-cbc; http://www.w3.org/2001/04/xmlenc#aes256-cbc

The AES algorithm is described in [AES]. XML Encryption implementations MUST support AES with 128 bit and 256 bit keys and MAY support AES with 192 bit keys. 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 before being encoded in base64 for inclusion in XML output. 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 bytes to produce the cipher text on encryption and with the cipher text bytes to produce plain text on decryption.

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.

5.3.1 ARCFOUR

Identifier: http://www.w3.org/2001/04/xmlenc#arcfour

ARCFOUR is an fast simple stream encryption algorithm that is compatible with RSA Security's RC4(tm) algorithm. It takes an optional KeySize explicit parameter. In cases where the key size is not apparent, 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 should be returned. An example of an ARCFOUR EncryptionMethod is as follows:

   <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#arcfour">
      <KeySize>40</KeySize>
   </EncryptionMethod>

Implementation of ARCFOUR 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. The type of key being transported is given by the Type attribute of the EncryptedKey element. This attribute value must be the URI of an encryption algorithm.

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

This is the RSAES-PKCS1-v1_5 algorithm described in RFC 2437 [PKCS1]. The RSA-PKCS1-v1_5 algorithm 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 CipherData 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 3DES and 128, 192, or 256 bits for AES. Support of this key transport algorithm for transporting 3DES keys is mandatory to implement. Support of this algorithm for transporting AES and ARCFOUR 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

This is the RSAES-OAEP-ENCRYPT algorithm described in RFC 2437 [PKCS1]. The RSA-OAEP 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 UTF-8 encoding of the text child of an optional OAEPparams element with white space (space, tab, CR, and LF) stripped. An example of an RSA-OAEP element is:

   <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep">
      <DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
      <OAEPparams> foo </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.

Encryption applications MUST implement RSA-OAEP for the transport of 128 and 256 bit AES keys. They MAY implement RSA-OAEP for the transport of 192 bit AES keys, 3DES keys, and ARCFOUR 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. 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 and, in fact, the Type attribute in this grandparent EncryptedData or EncryptedKey is an implicit parameter to the key agreement computation. In addition, the sender may include 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> foo </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="enc:AgreementMethodType"/>
   <complexType name="AgreementMethodType" mixed="true">
     <sequence>
       <element name="Nonce" minOccurs="0" type="string"/>
       <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>

The AgreementMethod will derive some shared secret octet sequence ZZ. The amount of actual 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 is the message digest algorithm specified by the DigestMethod child of AgreementMethod. EncryptionAlg is 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. Nonce is the UTF-8 serialization of the text child of the Nonce child of AgreementMethod, if present, with white space (space, tab, CR, and LF) stripped. If the Nonce element is absent, it is null. Counter is a one byte counter. KeySize is 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 ARCFOUR, it may be explicitly provided. For example, the initial (KM(1)) calculation for the example above, with ZZ not replaced by the binary shared secret octet sequence and the binary "1" counter byte represented as %01, would be calculated as follows:

SHA-256 ( Example:Block/AlgorithmZZ%01foo40 )

Each application of DigestAlg will produces some 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.5.1 Diffie-Hellman Key Values

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

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="enc: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

Diffie-Hellman (DH) key agreement 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 pubic 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:

   <AgreementMethod Algorithm="http://www.w3.org/2001/04/xmlenc#dh">
      <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"><X509Data><X509Certificate>
         ...
      </X509Certificate></X509Data></KeyInfo>
    </AgreementMethod>

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. The type of the key being wrapped is indicated by the Type attribute of EncryptedKey.

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

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

5.6.2 CMS Triple DES Key Wrap

Identifiers:: http://www.w3.org/2001/04/xmlenc#kw-3des

The type of the key being wrapped is given by the Type attribute of the parent EncryptedKey element. XML Encryption applications MUST support 3DES wrapping of 3DES keys and may optionally support 3DES wrapping of AES keys. An example of a 3DES Key Wrap EncryptionMethod element is a as follows:

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

The following algorithm wraps (encrypts) a key (the wrapped key, WK) under a 3DES key-encryption-key (KEK):

Represent the key being wrapped as an octet sequence. If it is a 3DES key, this is 24 octets (192 bits) produced by inserting an odd parity bit as the bottom bit of each octet. Call this representation WK.
Compute the key checksum defined in 5.5.1 above, call this CKS.
Let WKCKS = WK || CKS where || is concatenation.
Generate 8 random octets and call this IV.
Encrypt WKCKS in CBC mode using KEK as the key and IV as the initialization vector. Call the results TEMP1.
Let TEMP2 = IV || TEMP1.
Reverse the order of the octets in TEMP2 and call the result TEMP3.
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 3DES key is being wrapped.

The following algorithm unwraps (decyrpts) a key:

Check if the length of the cipher text is reasonable given the key type. It must be 40 bytes for a 3DES key and either 32, 40, or 48 bytes for an AES key. If the length is wrong, return error.
Decrypt the cipher text with 3DES in CBC mode using the KEK and an initialization vector (IV) of 0x4adda22c79e82105. Call the output TEMP3.
Reverse the order of the octets in TEMP3 and call the result TEMP2.
Decompose TEMP2 into IV, the first 8 octets, and TEMP1, the remaining octets.
Decrypt TEMP1 using 3DES in CBC mode using the KEK and the IV found in the previous step. Call the result WKCKS.
Decompose WKCKS. CKS is the last 8 octets and WK, the wrapped key, are those octets before the CKS.
Calculate a CMS Key Checksum, as described in Section 5.5.1, over the WK and compare with the CKS extracted in the above step. If they are not equal, return error.
WK is the wrapped key, now extracted for use in data decryption.

The above specification is that given in [CMS-Algorithms].

5.6.3 AES KeyWrap

Identifiers:: http://www.w3.org/2001/04/xmlenc#kw-aes128; http://www.w3.org/2001/04/xmlenc#kw-aes192; http://www.w3.org/2001/04/xmlenc#kw-aes256

Implementation of AES key wrap as specified by NIST/NSA/CMS will be mandatory for AES 128 and AES 256 and recommended for AES 192 -- when it's completely specified.

5.7 Message Digest

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

5.7.1 SHA1

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

The SHA-1 algorithm [SHA] takes no explicit parameters. XML encryption applications 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

The SHA-256 algorithm [SHA] takes no explicit parameters. It is RECOMMENDED that XML encryption applications 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

The SHA-512 algorithm [SHA] takes no explicit parameters. XML encryption applications MAY implement SHA-512. 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

The RIPEMD-160 algorithm [RIPEMD-160] takes no explicit parameters. XML encryption applications may implement RIPEMD-160. 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#

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

5.9 Canonicalization

Identifiers:: http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments; http://www.w3.org/TR/2001/REC-xml-c14n-20010315

If XML is to be encrypted it must first be serialized into an octet stream If it 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 [Canon]. Although this is not, properly speaking, a part of the encryption/decryption process, it is RECOMMENDED that XML encryption applications implement Canonical XML With Comments and they MAY also implement Canonical XML (without comments).

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:

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.
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, that symmetric key should only be used for the data intended for those multiple recipients because even if they are not directed to information encrypted in that symmetric key, they may be able to discover and decrypt it.

7 Schema, and Valid Examples

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

8 Issues

...

9 References

3DES: ANSI. Triple Data Encryption Algorithm Modes of Operation, ANSI X9.52, 1998.
AES: Joan Daemen and Vincent Rijmen. AES Proposal: Rijndael, 2000.
CMS-AES: Work in Progress. draft-ietf-smime-aes-alg-01.txt Use of the Advanced Encryption Algorithm in CMS. J. Schaad, R. Housley. March 2001.
CMS-Algorithms: Work in Progress. draft-ietf-smime-cmsalg-00.txt Cryptographic Message Syntax (CMS) Algorithms. R. Housley. April 2001.
DES: NIST FIPS 46-3. Data Encryption Standard. October 1999.
DOM: 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.; http://www.w3.org/TR/1998/REC-DOM-Level-1-19981001/
EncReq: Joseph Reagle. XML Encryption Requirements.
ESDH: Eric Rescorla. Diffie-Hellman Key Agreement Method, RFC 2631, 1999.
HMAC: RFC 2104. HMAC: Keyed-Hashing for Message Authentication. H. Krawczyk, M. Bellare, R. Canetti. February 1997.; http://www.ietf.org/rfc/rfc2104.txt
HTTP: RFC 2616. Hypertext Transfer Protocol -- HTTP/1.1. 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, W3C Working Draft. John Cowan.; http://www.w3.org/TR/xml-infoset/.
KEYWORDS: RFC 2119 Key words for use in RFCs to Indicate Requirement Levels. S. Bradner. March 1997.; http://www.ietf.org/rfc/rfc2119.txt
MD5: RFC 1321. The MD5 Message-Digest Algorithm. 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. N. Freed & N. Borenstein. November 1996.; http://www.ietf.org/rfc/rfc2045.txt
prop1: XML Encryption strawman proposal. Ed Simon and Brian LaMacchia. Aug 09 2000.
prop2: Another proposal of XML Encryption. Takeshi Imamura. Aug 14 2000.
prop3: XML Encryption Syntax and Processing. Dillaway, Fox, Imamura, LaMacchia, Maruyama, Schaad, Simon. December 2000.
PKCS1: RFC 2437. PKCS #1: RSA Cryptography Specifications Version 2.0. B. Kaliski, J. Staddon. October 1998.; http://www.ietf.org/rfc/rfc2437.txt
RANDOM: RFC 1750. Randomness Recommendations for Security. D. Eastlake, S. Crocker, J. Schiller. December 1994.
RIPEMD-160: CryptoBytes, Volume 3, Number 2. The Cryptographic Hash Function RIPEMD-160. RSA Laboratories. Autumn 1997.
SHA: NIST FIPS 180-1. Secure Hash Standard. 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. P. Hoffman , F. Yergeau. February 2000.; http://www.ietf.org/rfc/rfc2781.txt
UTF-8: RFC 2279. UTF-8, a transformation format of ISO 10646. F. Yergeau. January 1998.; http://www.ietf.org/rfc/rfc2279.txt
URI: RFC 2396. Uniform Resource Identifiers (URI): Generic Syntax. 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. R. Hinden, B. Carpenter, L. Masinter. December 1999.; http://www.ietf.org/rfc/rfc2732.txt
URL: RFC 1738. Uniform Resource Locators (URL). Berners-Lee, T., Masinter, L., and M. McCahill. December 1994.; http://www.ietf.org/rfc/rfc1738.txt
URN: RFC 2141. URN Syntax. R. Moats. May 1997.; http://www.ietf.org/rfc/rfc2141.txt; RFC 2611. URN Namespace Definition Mechanisms. L. 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. W3C Recommendation. T. Bray, J. Paoli, C. M. Sperberg-McQueen. February 1998.; http://www.w3.org/TR/1998/REC-xml-19980210
XML-C14N: Canonical XML. W3C Proposed Recommendation. J. Boyer. March 2001.; http://www.w3.org/TR/2001/REC-xml-c14n-20010315; http://www.ietf.org/rfc/rfc3076.txt
XMLDSIG: XML-Signature Syntax and Processing. Working Draft. D. Eastlake, J. Reagle, and D. Solo.; http://www.w3.org/TR/2000/CR-xmldsig-core-20001031/
XML-MT: RFC 2376. XML Media Types. E. Whitehead, M. Murata. July 1998.; http://www.ietf.org/rfc/rfc2376.txt
XML-NS: Namespaces in XML W3C 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 W3C Candidate Recommendation. D. Beech, M. Maloney, N. Mendelsohn. May 2001.; http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/; XML Schema Part 2: Datatypes W3C Candidate Recommendation. P. Biron, A. Malhotra. May 2001.; http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/