XML Encryption Syntax and Processing Version 1.1

3.3.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 the 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 defined in XML Signature [XMLDSIG-CORE1], however XML Encryption places the Transforms element in the XML Encryption namespace since it is used in XML Encryption to obtain an octet stream for decryption. In [XMLDSIG-CORE1] 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="https://www.example.com/CipherValues.xml">
  <Transforms>
    <ds:Transform Algorithm="https://www.w3.org/TR/1999/REC-xpath-19991116">
      <ds:XPath xmlns:xenc="https://www.w3.org/2001/04/xmlenc#">
        self::text()[parent::enc:CipherValue[@Id="example1"]]
      </ds:XPath>
    </ds:Transform>
    <ds:Transform Algorithm="https://www.w3.org/2000/09/xmldsig#base64"/>
  </Transforms>
</CipherReference>

Implementations MUST support the CipherReference feature and the same URI encoding, dereferencing, scheme, and HTTP response codes as that of [XMLDSIG-CORE1]. The Transform feature and particular transform algorithms are OPTIONAL.

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.5.1 The EncryptedKey Element

Identifier

Type="https://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). When EncryptedKey is decrypted the resulting octets are made available to the EncryptionMethod algorithm without any additional processing.

Schema Definition:

<element name="carview.php?tsp=EncryptedKey" type="xenc:EncryptedKeyType"/>
<complexType name="EncryptedKeyType">
  <complexContent>
    <extension base="xenc:EncryptedType">
      <sequence>
        <element ref="xenc:ReferenceList" minOccurs="0"/>
        <element name="CarriedKeyName" type="string" minOccurs="0"/>
      </sequence>
      <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 element 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 MUST be the same in all EncryptedKey elements identified with the same CarriedKeyName label within a single XML document. Note that because whitespace is significant in the value of the ds:KeyName element, whitespace is also significant in the value of the CarriedKeyName element.

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.

The Type attribute inherited from EncryptedType can be used to further specify the type of the encrypted key if the EncryptionMethod Algorithm does not define a unambiguous encoding/representation. (Note, all the algorithms in this specification have an unambiguous representation for their associated key structures.)

3.5.2 The DerivedKey Element

Identifier

Type="https://www.w3.org/2009/xmlenc11#DerivedKey"

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

The DerivedKey element is used to transport information about a derived key from the originator to recipient(s). It may be used as a stand-alone XML document, be placed within an application document, or appear inside an EncryptedData or Signature element as a child of a ds:KeyInfo element. The key value itself is never sent by the originator. Rather, the originator provides information to the recipient(s) by which the recipient(s) can derive the same key value. When the key has been derived the resulting octets are made available to the EncryptionMethod or SignatureMethod algorithm without any additional processing.

Schema Definition:

<!-- targetNamespace=&#x27;https://www.w3.org/2009/xmlenc11#&#x27; -->
<element name="carview.php?tsp=DerivedKey" type="xenc11:DerivedKeyType"/> 
<complexType name="DerivedKeyType">
  <sequence>
    <element ref="xenc11:KeyDerivationMethod" minOccurs="0"/>
    <element ref="xenc:ReferenceList" minOccurs="0"/>
    <element name="DerivedKeyName" type="string" minOccurs="0"/>
    <element name="MasterKeyName" type="string" minOccurs="0"/>
  </sequence>
  <attribute name="Recipient" type="string" use="optional"/>
  <attribute name="Id" type="ID" use="optional"/>
  <attribute name="Type" type="anyURI" use="optional"/>
</complexType>
<element name="KeyDerivationMethod" type="xenc:KeyDerivationMethodType"/>
<complexType name="KeyDerivationMethodType">
  <sequence>
    <any namespace="##any" minOccurs="0" maxOccurs="unbounded"/>
  </sequence>
  <attribute name="Algorithm" type="anyURI" use="required"/>
</complexType>

KeyDerivationMethod is an optional element that describes the key derivation algorithm applied to the master (underlying) key material. If the element is absent, the key derivation algorithm must be known by the recipient or the recipient's key derivation will fail.

ReferenceList is an optional element containing pointers to data and keys encrypted using this key. The reference list may contain multiple references to EncryptedKey or EncryptedData elements. This is done using KeyReference and DataReference elements from XML Encryption.

The optional DerivedKeyName element is used to identify the derived key value. This element may then be referenced by the ds:KeyName element in ds:KeyInfo. The same DerivedKeyName label, unlike an ID type, may occur multiple times within a single document. Note that because whitespace is significant in the value of the ds:KeyName element, whitespace is also significant in the value of the DerivedKeyName element.

MasterKeyName is an optional element for associating a user readable name with the master key (or secret) value. The same MasterKeyName label, unlike an ID type, may occur multiple times within a single document. The value of the master key MUST be the same in all DerivedKey elements identified with the same MasterKeyName label within a single XML document. If no MasterKeyName is provided, the master key material must be known by the recipient or key derivation will fail.

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

The optional Id attribute provides for the standard method of assigning a string id to the element within the document context.

The Type attribute can be used to further specify the type of the derived key if the KeyDerivationMethod algorithm does not define an unambiguous encoding/representation.

3.5.3 The ds:RetrievalMethod Element

The ds:RetrievalMethod [XMLDSIG-CORE1] with a Type of 'https://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 [XMLDSIG-CORE1] with a Type of 'https://www.w3.org/2001/04/xmlenc#DerivedKey' provides a way to express a link to a DerivedKey element used to derive the key needed to decrypt the CipherData associated with an EncryptedData or EncryptedKey element. The ds:RetrievalMethod with one of these types 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.

4.5.1 A Decrypt Implementation (Non-normative)

Where P is the context in which the serialized XML should be parsed (a document node or element node) and O is the octet sequence representing UTF-8 encoded characters resulting from step 4.3 in section 4.4 Decryption. Y is node-set representing the decrypted content obtained by the following steps:

1. Let C be the parsing context of a child of P, which consists of the following items:
   • Prefix and namespace name of each namespace that is in scope for P.
   • Name and value of each general entity that is effective for the XML document causing P.
2. Wrap the decrypted octet stream O in the context C as specified in section 4.5.4 Text Wrapping.
3. Parse the wrapped octet stream as described in The Reference Processing Model (section 4.3.3.2) of [XMLDSIG-CORE1], resulting in a node-set.
4. Y is the node-set obtained by removing the root node, the wrapping element node, and its associated set of attribute and namespace nodes from the node-set obtained in Step 3.

4.5.2 A Decrypt and Replace Implementation (Non-normative)

Where X is the [XPATH] node set corresponding to an XML document and e is an EncryptedData element node in X.

1. Z is an [XPATH] node-set that identical to X except where the element node e is an EncryptedData element type. In which case:
   1. Decrypt e in the context of its parent node as specified in the section 4.5.1 A Decrypt Implementation (Non-normative) yielding Y, an [XPATH] node set.
   2. Include Y in place of e and its descendants in X. Since [XPATH] does not define methods of replacing node-sets from different documents, the result MUST be equivalent to replacing e with the octet stream resulting from its decryption in the serialized form of X and re-parsing the document. However, the actual method of performing this operation is left to the implementor.

4.5.3 Serializing XML (Non-normative)

<Document xmlns="https://example.org/">
  <ToBeEncrypted xmlns="" />
</Document>

<Document xmlns="https://example.org/">
  <EncryptedData xmlns="...">
    <!-- Containing the encrypted "<ToBeEncrypted></ToBeEncrypted>" -->
  </EncryptedData>
</Document>

<Document xmlns="https://example.org/">
  <ToBeEncrypted/>
</Document> 

<ToBeEncrypted xmlns=""></ToBeEncrypted>

<Bongo href="example.xml"/>

<Baz xml:base="https://example.org/"/>

<Baz xml:base="https://example.org/"><Bongo href="example.xml"/></Baz>

5.1.1 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 for each algorithm.

Block Encryption

1. REQUIRED TRIPLEDES
   https://www.w3.org/2001/04/xmlenc#tripledes-cbc
2. REQUIRED AES-128
   https://www.w3.org/2001/04/xmlenc#aes128-cbc
3. REQUIRED AES-256
   https://www.w3.org/2001/04/xmlenc#aes256-cbc
4. REQUIRED AES128-GCM
   https://www.w3.org/2009/xmlenc11#aes128-gcm
5. OPTIONAL AES-192
   https://www.w3.org/2001/04/xmlenc#aes192-cbc
6. OPTIONAL AES192-GCM
   https://www.w3.org/2009/xmlenc11#aes192-gcm
7. OPTIONAL AES256-GCM
   https://www.w3.org/2009/xmlenc11#aes256-gcm

Note: Use of AES GCM is strongly recommended over any CBC block encryption algorithms as recent advances in cryptanalysis [XMLENC-CBC-ATTACK][XMLENC-CBC-ATTACK-COUNTERMEASURES] have cast doubt on the ability of CBC block encryption algorithms to protect plain text when used with XML Encryption. Other mitigations should be considered when using CBC block encryption, such as conveying the encrypted data over a secure channel such as TLS. The CBC block encryption algorithms that are listed as required remain so for backward compatibility.

Stream Encryption

1. none
   Syntax and recommendations are given below to support user specified algorithms.

Key Derivation

1. REQUIRED ConcatKDF
   https://www.w3.org/2009/xmlenc11#ConcatKDF
2. OPTIONAL PBKDF2
   https://www.w3.org/2009/xmlenc11#pbkdf2

Key Transport

1. REQUIRED RSA-OAEP (including MGF1 with SHA1)
   https://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p
2. Optional RSA-OAEP
   https://www.w3.org/2009/xmlenc11#rsa-oaep
3. OPTIONAL RSA-v1.5 (see RSA-v1.5 security note)
   https://www.w3.org/2001/04/xmlenc#rsa-1_5

Key Agreement

1. REQUIRED Elliptic Curve Diffie-Hellman (Ephemeral-Static mode)
   https://www.w3.org/2009/xmlenc11#ECDH-ES
2. OPTIONAL Diffie-Hellman Key Agreement (Ephemeral-Static mode) with Legacy Key Derivation Function
   https://www.w3.org/2001/04/xmlenc#dh
3. OPTIONAL Diffie-Hellman Key Agreement (Ephemeral-Static mode) with explicit Key Derivation Functions
   https://www.w3.org/2009/xmlenc11#dh-es

Symmetric Key Wrap

1. REQUIRED TRIPLEDES KeyWrap
   https://www.w3.org/2001/04/xmlenc#kw-tripledes
2. REQUIRED AES-128 KeyWrap
   https://www.w3.org/2001/04/xmlenc#kw-aes128
3. REQUIRED AES-256 KeyWrap
   https://www.w3.org/2001/04/xmlenc#kw-aes256
4. OPTIONAL AES-192 KeyWrap
   https://www.w3.org/2001/04/xmlenc#kw-aes192

Message Digest

1. REQUIRED SHA1 (Use is DISCOURAGED; see below).
   https://www.w3.org/2000/09/xmldsig#sha1
2. REQUIRED SHA256
   https://www.w3.org/2001/04/xmlenc#sha256
3. OPTIONAL SHA384
   https://www.w3.org/2001/04/xmlenc#sha384
4. OPTIONAL SHA512
   https://www.w3.org/2001/04/xmlenc#sha512
5. OPTIONAL RIPEMD-160
   https://www.w3.org/2001/04/xmlenc#ripemd160

Canonicalization

1. OPTIONAL Canonical XML 1.0 (omit comments)
   https://www.w3.org/TR/2001/REC-xml-c14n-20010315
2. OPTIONAL Canonical XML 1.0 (with comments)
   https://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments
3. OPTIONAL Canonical XML 1.1 (omit comments)
   https://www.w3.org/2006/12/xml-c14n11
4. OPTIONAL Canonical XML 1.1 (with comments)
   https://www.w3.org/2006/12/xml-c14n11#WithComments
5. OPTIONAL Exclusive XML Canonicalization 1.0 (omit comments)
   https://www.w3.org/2001/10/xml-exc-c14n#
6. OPTIONAL Exclusive XML Canonicalization 1.0 (with comments)
   https://www.w3.org/2001/10/xml-exc-c14n#WithComments

Encoding

1. REQUIRED base64 (*note)
   https://www.w3.org/2000/09/xmldsig#base64

Transforms

1. REQUIRED base64 (*note)
   https://www.w3.org/2000/09/xmldsig#base64

5.2.1 Padding

Since the data being encrypted is an arbitrary number of octets, it may not be a multiple of the block size. This is solved by padding the plain text up to the block size before encryption and unpadding after decryption. The padding algorithm is to calculate the smallest non-zero number of octets, say N, that must be suffixed to the plain text to bring it up to a multiple of the block size. We will assume the block size is B octets so N is in the range of 1 to B. Pad by suffixing the plain text with N-1 arbitrary pad bytes and a final byte whose value is N. On decryption, just take the last byte and, after sanity checking it, strip that many bytes from the end of the decrypted cipher text.

For example, assume an 8 byte block size and plain text of 0x616263. The padded plain text would then be 0x616263????????05 where the "??" bytes can be any value. Similarly, plain text of 0x2122232425262728 would be padded to 0x2122232425262728??????????????08.

5.2.2 Triple DES

Identifier:

https://www.w3.org/2001/04/xmlenc#tripledes-cbc

NIST SP800-67 [SP800-67] 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.

Note: Each of these 64 bits of key contain 56 effective bits and 8 parity bits. Thus there are only 168 operational bits out of the 192 being transported for a TRIPLEDES key. (Depending on the criterion used for analysis, the effective strength of the key may be thought to be 112 bits (due to meet in the middle attacks) or even less.)

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="https://www.w3.org/2001/04/xmlenc#tripledes-cbc" />

Note: CBC block encryption algorithms should not be used without consideration of possibly severe security risks.

5.2.3 AES

Identifier:

https://www.w3.org/2001/04/xmlenc#aes128-cbc

https://www.w3.org/2001/04/xmlenc#aes192-cbc

https://www.w3.org/2001/04/xmlenc#aes256-cbc

[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="https://www.w3.org/2001/04/xmlenc#aes128-cbc" />

Note: CBC block encryption algorithms should not be used without consideration of possibly severe security risks.

5.2.4 AES-GCM

Identifier:

https://www.w3.org/2009/xmlenc11#aes128-gcm

https://www.w3.org/2009/xmlenc11#aes192-gcm

https://www.w3.org/2009/xmlenc11#aes256-gcm

AES-GCM [SP800-38D] is an authenticated encryption mechanism. It is equivalent to doing these two operations in one step - AES encryption followed by HMAC signing.

AES-GCM is very attractive from a performance point of view because the cost of AES-GCM is similar to regular AES-CBC encryption, yet it achieves the same result as encryption and HMAC signing. Also AES-GCM can be pipelined so it is amenable to hardware acceleration.

For the purposes of this specification, AES-GCM shall be used with a 96 bit Initialization Vector (IV) and a 128 bit Authentication Tag (T). The cipher text contains the IV first, followed by the encrypted octets and finally the Authentication tag. No padding should be used during encryption. During decryption the implementation should compare the authentication tag computed during decryption with the specified Authentication Tag, and fail if they don't match. For details on the implementation of AES-GCM, see [SP800-38D].

5.4.1 ConcatKDF

Identifier:

https://www.w3.org/2009/xmlenc11#ConcatKDF

The ConcatKDF key derivation algorithm, defined in Section 5.8.1 of NIST SP 800-56A [SP800-56A] (and equivalent to the KDF3 function defined in ANSI X9.44-2007 [ANSI-X9-44-2007] when the contents of the OtherInfo parameter is structured as in NIST SP 800-56A), takes several parameters. These parameters are represented in the xenc11:ConcatKDFParamsType:

Schema Definition:

<!-- targetNamespace=&#x27;https://www.w3.org/2009/xmlenc11#&#x27; -->
<!-- use this element type as a child of xenc11:KeyDerivationMethod
     when used with ConcatKDF --> 
<element name="ConcatKDFParams" type="xenc11:ConcatKDFParamsType"/>
<complexType name="ConcatKDFParamsType">
  <sequence>
    <element ref="ds:DigestMethod"/>
  </sequence>
  <attribute name="AlgorithmID" type="hexBinary"/>
  <attribute name="PartyUInfo" type="hexBinary"/>
  <attribute name="PartyVInfo" type="hexBinary"/>
  <attribute name="SuppPubInfo" type="hexBinary"/>
  <attribute name="SuppPrivInfo" type="hexBinary"/>
</complexType>

The ds:DigestMethod element identifies the digest algorithm used by the KDF. Compliant implementations MUST support SHA-256 and SHA-1 (support for SHA-1 is present only for backwards-compatibility reasons). Support for SHA-384 and SHA-512 is OPTIONAL.

The AlgorithmID, PartyUInfo, PartyVInfo, SuppPubInfo and SuppPrivInfo attributes are as defined in [SP800-56A]. Their presence is optional but AlgorithmID, PartyVInfo and PartyUInfo MUST be present for applications that need to comply with [SP800-56A]. Note: The PartyUInfo component shall include a nonce when ConcatKDF is used in conjunction with a static-static Diffie-Hellman (or static-static ECDH) key agreement scheme; see further [SP800-56A].

In [SP800-56A], AlgorithmID, PartyUInfo, PartyVInfo, SuppPubInfo and SuppPrivInfo attributes are all defined as arbitrary-length bitstrings, thus they may need to be padded in order to be encoded into hexBinary for XML Encryption. The following padding and encoding method MUST be used when encoding bitstring values for the AlgorithmID, PartyUInfo, PartyVInfo, SuppPubInfo and SuppPrivInfo:

1. The bitstring is divided into octets using big-endian encoding. If the length of the bitstring is not a multiple of 8 then add padding bits (value 0) as necessary to the last octet to make it a multiple of 8.

2. Prepend one octet to the octets string from step 1. This octet shall identify (in a big-endian representation) the number of padding bits added to the last octet in step 1.

3. Encode the octet string resulting from step 2 as a hexBinary string.

Example: the bitstring 11011, which is 5 bits long, gets 3 additional padding bits to become the bitstring 11011000 (or D8 in hex). This bitstring is then prepended with one octet identifying the number of padding bits to become the octet string (in hex) 03D8, which then finally is encoded as a hexBinary string value of "03D8".

Note that as specified in [SP800-56A], these attributes shall be concatenated to form a bit string “OtherInfo” that is used with the key derivation function. The concatenation SHALL be done using the original, unpadded bit string values.” Applications MUST also verify that these attributes, in an application-specific way not defined in this document, identify algorithms and parties in accordance with NIST SP800-56.

An example of an xenc11:DerivedKey element with this key derivation algorithm given below. In this example, the bitstring value of AlgorithmID is 00000000, the bitstring value of PartyUInfo is 11011 and the bitstring value of PartyVInfo is 11010:

<xenc11:DerivedKey
    xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"
    xmlns:ds="https://www.w3.org/2000/09/xmldsig#"
    xmlns:xenc="https://www.w3.org/2001/04/xmlenc#"
    xmlns:xenc11="https://www.w3.org/2009/xmlenc11#">
  <xenc11:KeyDerivationMethod Algorithm="https://www.w3.org/2009/xmlenc11#ConcatKDF">
    <xenc11:ConcatKDFParams AlgorithmID="0000" PartyUInfo="03D8" PartyVInfo="03D0"> 
      <ds:DigestMethod Algorithm="https://www.w3.org/2001/04/xmlenc#sha256"/>
    </xenc11:ConcatKDFParams>
  </xenc11:KeyDerivationMethod>
  <xenc:ReferenceList>
    <xenc:DataReference URI="#ED"/>
  </xenc:ReferenceList>
  <xenc11:MasterKeyName>Our other secret</xenc11:MasterKeyName>
</xenc11:DerivedKey>

5.4.2 PBKDF2

Identifier:

https://www.w3.org/2009/xmlenc11#pbkdf2

The PBKDF2 key derivation algorithm and the ASN.1 type definitions for its parameters are defined in PKCS #5 v2.0 [PKCS5]. The XML schema definitions for the parameters is defined in [PKCS5Amd1] and the same can be specified by enclosing them within an xenc11:PBKDF2-params child element of the xenc11:KeyDerivationMethod element.

Schema Definition:

<element name="PBKDF2-params" type="xenc11:PBKDF2ParameterType"/>
<complexType name="PBKDF2ParameterType">
  <sequence>
    <element name="Salt">
      <complexType>
        <choice>
          <element name="Specified" type="base64Binary"/>
          <element name="OtherSource" type="xenc11:AlgorithmIdentifierType"/>
        </choice>
      </complexType>
    </element>
    <element name="IterationCount" type="positiveInteger"/>
    <element name="KeyLength" type="positiveInteger"/>
    <element name="PRF" type="xenc11:PRFAlgorithmIdentifierType"/>
  </sequence>
</complexType>
<complexType name="AlgorithmIdentifierType">
  <sequence>
    <element name="Parameters" type="anyType" minOccurs="0"/>
  </sequence>
  <attribute name="Algorithm" type="anyURI"/>
</complexType>
<complexType name="PRFAlgorithmIdentifierType">
  <complexContent>
    <restriction base="xenc11:AlgorithmIdentifierType">
      <attribute name="Algorithm" type="anyURI"/>
    </restriction>
  </complexContent>
</complexType>

(Note: A newline has been added to the Algorithm attribute to fit on this page, but is not part of the URI.)

The PBKDF2-params element and its child elements have the same names and meaning as the corresponding components of the PBKDF2-params ASN.1 type in [PKCS5]. Note, in case of ConcatKDF and the Diffie Hellman legacy KDF, KeyLength is an implied parameter and needs to be inferred from the context, but in the case of PBKDF2 the KeyLength child element has to be specified, as it has been made a mandatory parameter to be consistent with PKCS5. For PBKDF2, the inferred key length must match the specified key length, otherwise it is an error condition.

The AlgorithmIdentifierType corresponds to the AlgorithmIdentifier type of [PKCS5] and carries the algorithm identifier in the Algorithm attribute. Algorithm specific parameters, where applicable, can be specified using the Parameters element.

The PRFAlgorithmIdentifierType is derived from the AlgorithmIdentifierType and constrains the choice of algorithms to those contained in the PBKDF2-PRFs set defined in [PKCS5]. This type is used to specify a pseudorandom function (PRF) for PBKDF2. Whereas HMAC-SHA1 is the default PRF algorithm in [PKCS5], use of HMAC-SHA256 is RECOMMENDED by this specification (see [XMLDSIG-CORE1], [HMAC]).

An example of an xenc11:DerivedKey element with this key derivation algorithm is:

<xenc11:DerivedKey
    xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"
    xmlns:xenc="https://www.w3.org/2001/04/xmlenc#"
    xmlns:xenc11="https://www.w3.org/2009/xmlenc11#">
  <xenc11:KeyDerivationMethod Algorithm="https://www.w3.org/2009/xmlenc11#pbkdf2"/>
  <xenc11:PBKDF2-params>
    <xenc11:Salt>
      <xenc11:Specified>Df3dRAhjGh8=</xenc11:Specified>
    </xenc11:Salt>
    <xenc11:IterationCount>2000</xenc11:IterationCount>
    <xenc11:KeyLength>16</xenc11:KeyLength>
    <xenc11:PRF Algorithm="https://www.w3.org/2001/04/xmldsig-more#hmac-sha256"/>
  </xenc11:PBKDF2-params>
</xenc11:KeyDerivationMethod>
<xenc:ReferenceList>
  <xenc:DataReference URI="#ED"/>
</xenc:ReferenceList>
<xenc11:MasterKeyName>Our shared secret</xenc11:MasterKeyName>
</xenc11:DerivedKey>

5.5.1 RSA Version 1.5

Identifier:

https://www.w3.org/2001/04/xmlenc#rsa-1_5

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

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

The CipherValue for such an encrypted key is the base64 [RFC2045] encoding of the octet string computed as per RFC 3447 [PKCS1], section 7.2.1: Encryption operation]. As specified in the EME-PKCS1-v1_5 function RFC 3447 [PKCS1], section 7.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 192 bits for TRIPLEDES and 128, 192, or 256 bits for AES.

Implementations MUST support this key transport algorithm for transporting 192-bit TRIPLEDES keys. Support of this algorithm for transporting other keys is OPTIONAL. RSA-OAEP is RECOMMENDED for the transport of AES keys.

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

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

5.5.2 RSA-OAEP

Identifier:

https://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p (including MGF1 with SHA1 mask generation function)

Identifier:

https://www.w3.org/2009/xmlenc11#rsa-oaep

The RSAES-OAEP-ENCRYPT algorithm, as specified in RFC 3447 [PKCS1], has options that define the message digest function and mask generation function, as well as an optional PSourceAlgorithm parameter. Default values defined in RFC 3447 are SHA1 for the message digest and MGF1 with SHA1 for the mask generation function. Both the message digest and mask generation functions are used in the EME-OAEP-ENCODE operation as part of RSAES- OAEP-ENCRYPT.

The https://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p identifier defines the mask generation function as the fixed value of MGF1 with SHA1. In this case the optional xenc11:MGF element of the xenc:EncryptionMethod element MUST NOT be provided.

The https://www.w3.org/2009/xmlenc11#rsa-oaep identifier defines the mask generation function using the optional xenc11:MGF element of the xenc:EncryptionMethod element. If not present, the default of MGF1 with SHA1 is to be used.

The following URIs define the various mask generation function URI values that may be used. These correspond to the object identifiers defined in RFC 4055 [RFC4055]:

• MGF1 with SHA1: https://www.w3.org/2009/xmlenc11#mgf1sha1
• MGF1 with SHA224: https://www.w3.org/2009/xmlenc11#mgf1sha224
• MGF1 with SHA256: https://www.w3.org/2009/xmlenc11#mgf1sha256
• MGF1 with SHA384: https://www.w3.org/2009/xmlenc11#mgf1sha384
• MGF1 with SHA512: https://www.w3.org/2009/xmlenc11#mgf1sha512

Otherwise the two identifiers define the same usage of the RSA-OAEP algorithm, as follows.

The message digest function SHOULD be specified using the Algorithm attribute of the ds:DigestMethod child element of the xenc:EncryptionMethod element. If it is not specified, the default value of SHA1 is to be used.

The optional RSA-OAEP PSourceAlgorithm parameter value MAY be explicitly provided by placing the base64 encoded octets in the xenc:OAEPparams XML element.

The XML Encryption 1.0 schema definition and description for the EncryptionMethod element is in section 3.2 The EncryptionMethod Element. The following shows the XML Encryption 1.1 addition for the MGF type:

Schema Definition:

<element name="MGF" type="xenc11:MGFType"/>
<complexType name="MGFType">
  <complexContent>
    <restriction base="xenc11:AlgorithmIdentifierType">
      <attribute name="Algorithm" type="anyURI" use="required" />
    </restriction>
  </complexContent>
</complexType>

An example of an RSA-OAEP element is:

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

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

Another example is:

<EncryptionMethod Algorithm="https://www.w3.org/2009/xmlenc11#rsa-oaep">
  <OAEPparams>9lWu3Q==</OAEPparams>
  <xenc11:MGF Algorithm="https://www.w3.org/2001/04/xmlenc#MGF1withSHA1" />
  <ds:DigestMethod Algorithm="https://www.w3.org/2000/09/xmldsig#sha1" />
<EncryptionMethod>

The CipherValue for an RSA-OAEP encrypted key is the base64 [RFC2045] encoding of the octet string computed as per RFC 3447 [PKCS1], section 7.1.1: Encryption operation. As described in the EME-OAEP-ENCODE function RFC 3447 [PKCS1], section 7.1.1, the value input to the key transport function is calculated using the message digest function and string specified in the DigestMethod and OAEPparams elements and using either the mask generator function specified with the xenc11:MGF element or the default MGF1 with SHA1 specified in RFC 3447. The desired output length for EME-OAEP-ENCODE is one byte shorter than the RSA modulus.

The transported key size is 192 bits for TRIPLEDES and 128, 192, or 256 bits for AES. Implementations MUST implement RSA-OAEP for the transport of all key types and sizes that are mandatory to implement for symmetric encryption. They MAY implement RSA-OAEP for the transport of other keys.

5.6.1 Diffie-Hellman Key Values

Identifier:

https://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.

As specified in [ESDH], a DH public key consists of up to six quantities, two large primes p and q, a "generator" g, the public key, and validation parameters "seed" and "pgenCounter". These relate as follows: The public key = ( g**x mod p ) where x is the corresponding private key; p = j*q + 1 where j >= 2. "seed" and "pgenCounter" are optional and can be used to determine if the Diffie-Hellman key has been generated in conformance with the algorithm specified in [ESDH]. Because the primes 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 Definition:

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

5.6.2 Diffie-Hellman Key Agreement

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. The size of p MUST 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].

The Diffie-Hellman shared secret zz is used as the input to a KDF to produce a secret key. XML Signature 1.0 defined a specific KDF to be used with Diffie-Hellman; that KDF is now known as the "Legacy KDF" and is defined in Section 5.6.2.2. Use of Diffie-Hellman with explicit KDFs is described in Section 5.6.2.1.

Implementation of Diffie-Hellman key agreement is OPTIONAL. However, if implemented, such implementations MUST support the Legacy Key Derivation Function and SHOULD support Diffie-Hellman with explicit Key Derivation Functions

An example of a DH AgreementMethod element using the Legacy Key Derivation Function (Section 5.6.2.2) is as follows:

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

<xenc:AgreementMethod Algorithm="https://www.w3.org/2009/xmlenc11#dh-es">
  <xenc11:KeyDerivationMethod Algorithm="https://www.w3.org/2009/xmlenc11#ConcatKDF">
    <xenc11:ConcatKDFParams AlgorithmID="00" PartyUInfo="" PartyVInfo=""> 
      <ds:DigestMethod Algorithm="https://www.w3.org/2001/04/xmlenc#sha256"/>
    </xenc11:ConcatKDFParams>
  </xenc11:KeyDerivationMethod>
  <xenc:OriginatorKeyInfo>
    <ds:X509Data>
      <ds:X509Certificate><!-- X.509 Certificate here --></ds:X509Certificate>
    </ds:X509Data>
  </xenc:OriginatorKeyInfo>
  <xenc:RecipientKeyInfo>
    <ds:X509Data>
      <ds:X509SKI></ds:X509SKI>
      <!-- hint for the recipient's private key -->
    </ds:X509Data>
  </xenc:RecipientKeyInfo>
</xenc:AgreementMethod>

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

KM(counter) = DigestAlg ( ZZ | counter | EncryptionAlg |
            KA-Nonce | KeySize )

SHA-1 ( ZZ01Example:Block/Algfoo80 )

SHA-1( 0xDEADBEEF30314578616D706C653A426C6F636B2F416C67666F6F3830 )

0x534C9B8C4ABDCB50038B42015A181711068B08C1

5.6.3 Elliptic Curve Diffie-Hellman (ECDH) Key Values

Identifier:

https://www.w3.org/2009/xmldsig11#ECKeyValue

ECDH has identical public key parameters as ECDSA and can be represented with the ECKeyValue element [XMLDSIG-CORE1]. Note that if the curve parameters are explicitly stated using the ECParameters element, then the Cofactor element MUST be included.

As with Diffie-Hellman keys, Elliptic Curve Key Values 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.

5.6.4 Elliptic Curve Diffie-Hellman (ECDH) Key Agreement (Ephemeral-Static Mode)

Identifier:

https://www.w3.org/2009/xmlenc11#ECDH-ES

ECDH is the elliptic curve analogue to the Diffie-Hellman key agreement algorithm. Details of the ECDH primitive can be found in [ECC-ALGS]. When ECDH is used in Ephemeral-Static (ES) mode, the recipient has a static key pair, but the sender generates a ephemeral key pair for each message. The same ephemeral key may be used when there are multiple recipients that use the same curve parameters.

Compliant implementations are REQUIRED to support ECDH-ES key agreement using the P-256 prime curve specified in Section D.2.3 of FIPS 186-3 [FIPS-186-3]. (This is the same curve that is REQUIRED in XML Signature 1.1 to be supported for the ECDSAwithSHA256 algorithm.) It is further RECOMMENDED that implementations also support the P-384 and P-521 prime curves for ECDH-ES; these curves are defined in Sections D.2.4 and D.2.5 of FIPS 186-3, respectively.

The shared key material is calculated from the Diffie-Hellman shared secret using a key derivation function (KDF). While applications may define other KDFs, compliant implementations MUST implement ConcatKDF (see section 5.4.1 ConcatKDF). An example of xenc:EncryptedData using the ECDH-ES key agreement algorithm with the ConcatKDF key derivation algorithm is as follows:

<xenc:EncryptedData
    xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"
    xmlns:xenc="https://www.w3.org/2001/04/xmlenc#"
    xmlns:ds="https://www.w3.org/2000/09/xmldsig#"
    xmlns:dsig11="https://www.w3.org/2009/xmldsig11#"
    xmlns:xenc11="https://www.w3.org/2009/xmlenc11#"
    Type="https://www.w3.org/2001/04/xmlenc#">
  <xenc:EncryptionMethod Algorithm="https://www.w3.org/2001/04/xmlenc#aes128-cbc" />
  <!-- describes the encrypted AES content encryption key -->
  <ds:KeyInfo>
    <xenc:EncryptedKey>
      <xenc:EncryptionMethod Algorithm="https://www.w3.org/2001/04/xmlenc#kw-aes128"/>
      <!-- describes the key encryption key -->
      <ds:KeyInfo>
        <xenc:AgreementMethod Algorithm="https://www.w3.org/2009/xmlenc11#ECDH-ES">
          <xenc11:KeyDerivationMethod Algorithm="https://www.w3.org/2009/xmlenc11#ConcatKDF">
            <xenc11:ConcatKDFParams AlgorithmID="00" PartyUInfo="" PartyVInfo=""> 
              <ds:DigestMethod Algorithm="https://www.w3.org/2001/04/xmlenc#sha256"/>
            </xenc11:ConcatKDFParams>
          </xenc11:KeyDerivationMethod>
          <xenc:OriginatorKeyInfo>
            <ds:KeyValue>
              <dsig11:ECKeyValue>
                <!-- ephemeral ECC public key of the originator -->
              </dsig11:ECKeyValue>
            </ds:KeyValue>
          </xenc:OriginatorKeyInfo>
          <xenc:RecipientKeyInfo>
            <ds:X509Data>
              <ds:X509SKI></ds:X509SKI>
              <!-- hint for the recipient's private key -->
            </ds:X509Data>
          </xenc:RecipientKeyInfo>
        </xenc:AgreementMethod>
      </ds:KeyInfo>
      <xenc:CipherData>
        <xenc:CipherValue><!-- encrypted AES content encryption key --></xenc:CipherValue>
      </xenc:CipherData>
    </xenc:EncryptedKey>
  </ds:KeyInfo>
  
  <xenc:CipherData>
    <xenc:CipherValue>
      <!-- encrypted data -->
    </xenc:CipherValue>
  </xenc:CipherData>
  
</xenc:EncryptedData>

5.7.1 CMS Triple DES Key Wrap

Identifiers:

https://www.w3.org/2001/04/xmlenc#kw-tripledes

XML Encryption implementations MUST support TRIPLEDES wrapping of 168 bit keys as described in [CMS-WRAP] and may optionally support TRIPLEDES wrapping of other keys.

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

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

5.7.2 AES KeyWrap

Identifiers:

https://www.w3.org/2001/04/xmlenc#kw-aes128

https://www.w3.org/2001/04/xmlenc#kw-aes192

https://www.w3.org/2001/04/xmlenc#kw-aes256

Implementation of AES key wrap is described in [AES-WRAP]. It provides for confidentiality and integrity. This algorithm is defined only for inputs which are a multiple of 64 bits. The information wrapped need not actually be a key. The algorithm is the same whatever the size of the AES key used in wrapping, called the key encrypting key or KEK. The implementation requirements are indicated below.

128 bit AES Key Encrypting Key

Implementation of wrapping 128 bit keys REQUIRED.
Wrapping of other key sizes OPTIONAL.

192 bit AES Key Encrypting Key

All support OPTIONAL.

256 bit AES Key Encrypting Key

Implementation of wrapping 256 bit keys REQUIRED.
Wrapping of other key sizes OPTIONAL.

5.8.1 SHA1

Identifier:

https://www.w3.org/2000/09/xmldsig#sha1

The SHA-1 algorithm [FIPS-180-3] takes no explicit parameters. An example of an SHA-1 DigestMethod element is:

<DigestMethod Algorithm="https://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.8.2 SHA256

Identifier:

https://www.w3.org/2001/04/xmlenc#sha256

The SHA-256 algorithm [FIPS-180-3] takes no explicit parameters. An example of an SHA-256 DigestMethod element is:

<DigestMethod Algorithm="https://www.w3.org/2001/04/xmlenc#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.8.3 SHA384

Identifier:

https://www.w3.org/2001/04/xmlenc#sha384

The SHA-384 algorithm [FIPS-180-3] takes no explicit parameters. An example of an SHA-384 DigestMethod element is:

<DigestMethod Algorithm="https://www.w3.org/2001/04/xmlenc#sha384" />

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

5.8.4 SHA512

Identifier:

https://www.w3.org/2001/04/xmlenc#sha512

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

<DigestMethod Algorithm="https://www.w3.org/2001/04/xmlenc#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.8.5 RIPEMD-160

Identifier:

https://www.w3.org/2001/04/xmlenc#ripemd160

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

<DigestMethod Algorithm="https://www.w3.org/2001/04/xmlenc#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.9.1 Inclusive Canonicalization

Identifiers:

https://www.w3.org/TR/2001/REC-xml-c14n-20010315

https://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments

https://www.w3.org/2006/12/xml-c14n11

https://www.w3.org/2006/12/xml-c14n11#WithComments

Canonical XML [XML-C14N11] is a method of serializing XML which includes the in scope namespace and xml namespace attribute context from ancestors of the XML being serialized.

If XML is to be encrypted and then later decrypted into a different environment and it is desired to preserve namespace prefix bindings and the value of attributes in the "xml" namespace of its original environment, then the canonical XML with comments version of the XML should be the serialization that is encrypted.

5.9.2 Exclusive Canonicalization

Identifiers:

https://www.w3.org/2001/10/xml-exc-c14n#

https://www.w3.org/2001/10/xml-exc-c14n#WithComments

Exclusive XML Canonicalization [XML-EXC-C14N] serializes XML in such a way as to include to the minimum extent practical the namespace prefix binding and xml namespace attribute context inherited from ancestor elements.

It is the recommended method where the outer context of a fragment which was signed and then encrypted may be changed. Otherwise the validation of the signature over the fragment may fail because the canonicalization by signature validation may include unnecessary namespaces into the fragment.

6.1.1 Attacks against the encrypted data (<EncryptedData> part)

Using the CBC-based chosen-ciphertext attacks, the attacker sends to the server an XML document with modified encrypted data in the symmetric part (<EncryptedData>). After a few requests, the attacker is able to get the whole cleartext without knowledge of the symmetric key.

It would seem that these attacks can be countered by by disrupting any of the conditions, however in practice only preventing condition 3 (sending arbitrary ciphertext) is fully effective. To counter condition 3, it is necessary for the decrypting system to require authenticated integrity protection over the ciphertext. However, unless the mechanism used is bound to the encryption key, there will no way to be sure that the signer is not attempting to recover the plaintext. The simplest and most efficient way to do this is to use an authenticating block mode, such as GCM. An alternative would be an HMAC based on the encryption key over the ciphertext, but it is less efficient and provides no advantages.

Other countermeasures are not likely to be effective. Limiting the number of messages presented or the number of messages using the same key is not practical in large server farms. Attackers can spread their attempts over different servers and long or short periods of time, to foil attempts to detect attacks in progress or determine the location of the attacker.

Signaling well-formedness can occur by emitting different messages for distinct security errors or by exhibiting timing differences. Implementations should avoid these practices, however that is not sufficient to prevent such attacks in an XML protocol environment, such as SOAP. Using a technique called encryption wrapping, the attacker can insert the ciphertext in some schema-legal part of the message. If the decryption code notices a format error, an error will be returned, but if not the message will be passed to the application which will ignore the bogus plaintext and ultimately respond with an application level success or failure message.

6.1.2 Attacks against the encrypted key (Bleichenbacher's Million question attack on PKCS#1.5)

The goal of the attacker applying the Bleichenbacher's attack is to get the symmetric secret key, which is encrypted in the <EncryptedKey> part. Afterward, he would be able to decrypt the whole data carried in the <EncryptedData> part.

The basic idea of this attack is to modify the data in the <EncryptedKey> part, send the document to the server, and observe if the modified ciphertext contains PKCS#1.5 conformant data. This can be done by:

1. Observing fault messages of the server notifying directly that the request was not PKCS#1.5 conformant (this should not happen).
2. Enlarging the data in the <EncryptedData> part and observing the timing differences between inclusion of PKCS-valid and PKCS-invalid keys: if the key is PKCS-valid, the session key is extracted, and the large data is decrypted. Otherwise, the session key cannot be extracted and the large data is not processed, which yields a timing difference.
3. Making specific modifications of the <EncryptedData> part based on CBC and padding-properties.

These problems are described in detail in RFC 3218 [RFC3218].

The most effective countermeasure against the timing attack (2) is to generate a random secret key every time when the decrypted data was not PKCS#1-conformant. This way, the attacker would not get any timing side-channel.

Please note however that this is not a valid countermeasure against the specific modification of the <EncryptedData> described in part (3). The attacker could still use a few millions of requests to decrypt the encrypted symmetric key. Therefore, we recommend the usage of RSA-OAEP. RSA-OAEP also has a risk of a chosen ciphertext attack [OAEP-ATTACK] which can be mitigated in security library implementations.

6.1.3 Backwards Compatibility Attacks

Use of state-of-the-art and secure encryption algorithms such as RSA-OAEP and AES-GCM can become insecure when the adversary can force the server to process eavesdropped ciphertext with legacy algorithms such as RSA-PKCS#1 v1.5 or AES-CBC [XMLENC-BACKWARDS-COMP]:

1. The attacker may be able to break the security of an AES-GCM ciphertext if he is able to force the server to process the ciphertext with AES-CBC and the same symmetric key.
2. The attacker may be able to decrypt an RSA-OAEP ciphertext if he is able to force the server to process the ciphertext with RSA-PKCS#1 v1.5 and the same asymmetric key.
3. The attacker may be able to forge valid server signatures if the server decrypts RSA-PKCS#1 v1.5 ciphertexts and the signatures are computed with the same asymmetric key pair.

Accordingly, in situations where an attacker may be able to mount chosen-ciphertext attacks, we recommend the following to implementers:

1. Implementations SHOULD always use a different public key pair for data confidentiality and for data integrity functionality.
2. Implementations using symmetric keys SHOULD NOT use the same key material for different algorithms, even if serving the same purpose. Key derivation based on a single key and the algorithm identifier can be used to accomplish this, for example.
3. Implementations that plan to use the same symmetric key for both confidentiality and integrity functions SHOULD use it as the basis for a key derivation producing different keys for those functions.
4. Implementations SHOULD restrict algorithm usage to algorithms known to be secure in the face of chosen-ciphertext attacks (RSA-OAEP, AES-GCM). In that case, documents containing RSA-PKCS#1 v1.5 [XMLENC-PKCS15-ATTACK] and AES-CBC [XMLENC-CBC-ATTACK] ciphertexts SHOULD be rejected without decryption.