XML Encryption Syntax and Processing Version 1.1

link管理

链接快照平台

输入网页链接，自动生成快照
标签化管理网页链接

Abstract

This document specifies a process for encrypting data and representing the result in XML. The data may be in a variety of formats, including octet streams and other unstructured data, or structured data formats such as XML documents, an XML element, or XML element content. The result of encrypting data is an XML Encryption element that contains or references the cipher data.

Status of This Document

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C 's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.

The original version of this specification was produced by the W3C XML Encryption Working Group ; the Interoperability Report shows four implementations with at least two interoperable implementations over every feature.

Please refer to the implementation report for version 1.1 of this specification for additional details about the implementation status of features added in this revision.

Conformance-affecting changes against the previous Recommendation mainly affect the set of mandatory to implement cryptographic algorithms, by adding Elliptic Curve Diffie-Hellman Key Agreement, making AES-128 GCM mandatory, changing RSA v1.5 to optional, adding optional AES192-GCM and adding optional RSA-OEAP algorithm variants. Important security considerations have also been added. A detailed summary of changes is available in [ XMLENC-CORE1-CHGS ]. Changes are also described in a diff document showing changes since the original Recommendation , as well as a diff document showing changes since the previous PR draft . This document was published by the XML Security Working Group as a Recommendation. If you wish to make comments regarding this document, please send them to [email protected] ( subscribe , archives ). W3C maintains a public list of any patent disclosures made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains Essential Claim(s) must disclose the information in accordance with section 6 of the W3C Patent Policy .

Additional information related to the IPR status of XML Encryption 1.1 is also available.

1. Introduction
2. Encryption Overview and Examples
- 2.1 Encryption Granularity
- 2.2 EncryptedData and EncryptedKey Usage
  - 2.2.1 EncryptedData with Symmetric Key ( KeyName )
  - 2.2.2 EncryptedKey ( ReferenceList , ds:RetrievalMethod , CarriedKeyName )
3. Encryption Syntax
4. Processing Rules
5. Algorithms
6. Security Considerations
7. Conformance
8. XML Encryption Media Type
- 8.1 Introduction
- 8.2 application/xenc+xml Registration
9. Schema
- 9.1 XSD Schema
- 9.2 RNG Schema
A. Reserved Algorithm Identifiers
- A.1 AES KeyWrap with Padding
B. References
- B.1 Normative references
- B.2 Informative references

1. Introduction

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

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

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

1.1 Editorial and Conformance Conventions

This specification uses XML schemas [ XMLSCHEMA-1 ], [ XMLSCHEMA-2 ] to describe the content model. The full normative grammar is defined by the XSD schema and the normative text in this specification. The standalone XSD schema file is authoritative in case there is any disagreement between it and the XSD schema portions.

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 ]:

"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-NAMES ] is described as " REQUIRED ".

1.2 Design Philosophy

The design philosophy and requirements of this specification (including the limitations related to instance validity) are addressed in the original XML Encryption Requirements [ XML-ENCRYPTION-REQ ] and the XML Security 1.1 Requirements document [ XMLSEC11-REQS ].

1.3 Versions, Namespaces, URIs, and Identifiers

This specification makes use of XML namespaces, and uses Uniform Resource Identifiers [ URI ] to identify resources, algorithms, and semantics.

Implementations of this specification MUST use the following XML namespace URIs:

URInamespace prefixXML internal entity


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

default namespace ,


   xenc:


   <!ENTITY xenc "http://www.w3.org/2001/04/xmlenc#">


   http://www.w3.org/2009/xmlenc11#


   xenc11:


   <!ENTITY xenc11 "http://www.w3.org/2009/xmlenc11#">

The http://www.w3.org/2001/04/xmlenc# ( xenc: ) namespace was introduced in version 1.0 of this specification. The present version does not coin any new elements or algorithm identifiers in that namespace; instead, the http://www.w3.org/2009/xmlenc11# ( xenc11: ) namespace is used.

No provision is made for an explicit version number in this syntax. If a future version of this specification requires explicit versioning of the document format, a different namespace will be used.

Additionally, this specification uses elements and algorithm identifiers from the XML Signature name spaces [ XMLDSIG-CORE1 ]:

URInamespace prefixXML internal entity


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

default namespace ,

ds:


   dsig:


   <!ENTITY dsig "http://www.w3.org/2000/09/xmldsig#">


   http://www.w3.org/2009/xmldsig11#


   dsig11:


   <!ENTITY dsig11 "http://www.w3.org/2009/xmldsig11#">

1.4 Acknowledgements

The contributions of the following members of the original Working Group to the original XML Encryption specification are gratefully acknowledged in accordance with the contributor policies and the active WG roster : Joseph Ashwood, Simon Blake-Wilson, Certicom, Frank D. Cavallito, BEA Systems, Eric Cohen, PricewaterhouseCoopers, Blair Dillaway, Microsoft (Author), Blake Dournaee, RSA Security, Donald Eastlake, Motorola (Editor), Barb Fox, Microsoft, Christian Geuer-Pollmann, University of Siegen, Tom Gindin, IBM, Jiandong Guo, Phaos, Phillip Hallam-Baker, Verisign, Amir Herzberg, NewGenPay, Merlin Hughes, Baltimore, Frederick Hirsch, Maryann Hondo, IBM, Takeshi Imamura, IBM (Author), Mike Just, Entrust, Inc., Brian LaMacchia, Microsoft, Hiroshi Maruyama, IBM, John Messing, Law-on-Line, Shivaram Mysore, Sun Microsystems, Thane Plambeck, Verisign, Joseph Reagle, W3C (Chair, Editor), Aleksey Sanin, Jim Schaad, Soaring Hawk Consulting, Ed Simon, XMLsec (Author), Daniel Toth, Ford, Yongge Wang, Certicom, Steve Wiley, myProof.

Additionally, we thank the following for their comments during and subsequent to the Last Call of the original Recommendation: Martin Dürst, W3C , Dan Lanz, Zolera, Susan Lesch, W3C , David Orchard, BEA Systems, Ronald Rivest, MIT .

Contributions for version 1.1 were received from the members of the XML Security Working Group: Scott Cantor, Juan Carlos Cruellas, Pratik Datta, Gerald Edgar, Ken Graf, Phillip Hallam-Baker, Brad Hill, Frederick Hirsch, Brian LaMacchia, Konrad Lanz, Hal Lockhart, Cynthia Martin, Rob Miller, Sean Mullan, Shivaram Mysore, Magnus Nyström, Bruce Rich, Thomas Roessler, Ed Simon, Chris Solc, John Wray, Kelvin Yiu.

The working group also acknowledges the contribution of Juraj Somorovsky raising the issue of the CBC chosen ciphertext attack and contributions to revising the security considerations of XML Encryption 1.1.

2. Encryption Overview and Examples

This section is non-normative.

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

Expressed in shorthand form, the EncryptedData element has the following structure (where "?" denotes zero or one occurrence; "+" denotes one or more occurrences; "*" denotes zero or more occurrences; "|" denotes a choice; and the empty element tag means the element must be empty ):

Example 1

<EncryptedData Id? Type? MimeType? Encoding?>
  <EncryptionMethod/>?
  <ds:KeyInfo>
    <EncryptedKey>?
    <AgreementMethod>?
    <ds:KeyName>?
    <ds:RetrievalMethod>?
    <ds:*>?
  </ds:KeyInfo>?
  <CipherData>
    <CipherValue> | <CipherReference URI?>
  </CipherData>
  <EncryptionProperties>?
</EncryptedData>

The CipherData element envelopes or references the raw encrypted data. A CipherData element must have either a CipherValue or CipherReference child element. 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

This section is non-normative.

Note: Examples in this document do not consider plaintext guessing attacks or other risks, and are only for illustrative purposes.

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

Example 2

<?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>Example Bank</Issuer>
    <Expiration>04/02</Expiration>
  </CreditCard>
</PaymentInfo>

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

2.1.1 Encrypting an XML Element

This section is non-normative.

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

Example 3

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

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

2.1.2 Encrypting XML Element Content (Elements)

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

Example 4

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

2.1.3 Encrypting XML Element Content (Character Data)

Alternatively, 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:

Example 5

<?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>Example Bank</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 sequence. This applies to arbitrary data including XML documents.

Example 6

<?xml version="1.0"?>
<EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
               MimeType="text/xml">
  <CipherData>
    <CipherValue>A23B45C56</CipherValue>
  </CipherData>
</EncryptedData>

Where appropriate, such as in the case of encrypting an entire EXI stream, the Type attribute SHOULD be provided and indicate the use of EXI. The optional MimeType MAY be used to record the actual (non-EXI-encoded) type, but is not necessary and may be omitted, as in the following EXI encryption example:

Example 7

<?xml version="1.0"?> 
<EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
               Type="http://www.w3.org/2009/xmlenc11#EXI">
  <CipherData>
    <CipherValue>A23B45C56</CipherValue>
  </CipherData>
</EncryptedData>

2.1.5 Super-Encryption: Encrypting EncryptedData

An XML document may contain zero or more EncryptedData elements. EncryptedData cannot 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:

Example 8

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

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

Example 9

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

where the CipherValue content of ' 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` )

Example 10

[s01]<EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
                    Type="http://www.w3.org/2001/04/xmlenc#Element">
[s02]  <EncryptionMethod
           Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
[s03]  <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
[s04]    <ds:KeyName>John Smith</ds:KeyName>
[s05]  </ds:KeyInfo>
[s06]  <CipherData><CipherValue>DEADBEEF</CipherValue></CipherData>
[s07]</EncryptedData>

[s1] The type of data encrypted may be represented as an attribute value to aid in decryption and subsequent processing. In this case, the data encrypted was an 'element'. Other alternatives include 'content' of an element, or an external octet sequence which can also be identified via the MimeType and Encoding attributes.

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

[s4] The symmetric key has an associated name "John Smith".

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

2.2.2 `EncryptedKey` ( `ReferenceList` , `ds:RetrievalMethod` , `CarriedKeyName` )

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

Example 11

[t01]<EncryptedData Id="ED" 
                    xmlns="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>Sally Doe</ds:KeyName>
[t06]  </ds:KeyInfo>
[t07]  <CipherData><CipherValue>DEADBEEF</CipherValue></CipherData>
[t08]</EncryptedData>

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

[t04] ds:RetrievalMethod is used to indicate the location of a key with type xenc:EncryptedKey . The (AES) key is located at '#EK'.

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

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

Example 12

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

[t09] The EncryptedKey element is similar to the EncryptedData element except that the data encrypted is always a key value.

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

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

[t14] The CipherData 's CipherValue is an octet sequence that is processed (serialized, encrypted, and encoded) 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.)

[t15-17] 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.

[t18] The CarriedKeyName element is used to identify the encrypted key value which may be referenced by the KeyName element in ds:KeyInfo . (Since ID attribute values must be unique to a document, CarriedKeyName can indicate that several EncryptedKey structures contain the same key value encrypted for different recipients.)

3. Encryption Syntax

This section provides a detailed description of the syntax and features for XML Encryption. Features described in this section MUST be implemented unless otherwise noted. The syntax is defined via [ XMLSCHEMA-1 ], [ XMLSCHEMA-2 ] with the following XML preamble, declaration, internal entity, and import:

Schema Definition:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE schema  PUBLIC "-//W3C//DTD XMLSchema 200102//EN"
<!ATTLIST schema
xmlns:xenc CDATA #FIXED 'http://www.w3.org/2001/04/xmlenc'#
xmlns:ds CDATA #FIXED 'http://www.w3.org/2000/09/xmldsig#'>
<!ENTITY xenc 'http://www.w3.org/2001/04/xmlenc#'>
<!ENTITY % p ''>
<!ENTITY % s ''>
<schema xmlns="http://www.w3.org/2001/XMLSchema" version="1.0"
        xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
        xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
        targetNamespace="http://www.w3.org/2001/04/xmlenc#"
        elementFormDefault="qualified">
  <import namespace="http://www.w3.org/2000/09/xmldsig#"
          schemaLocation="http://www.w3.org/TR/2002/
            REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/>

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

Additional markup defined in this specification uses the xenc11: namespace. The syntax is defined in an XML schema with the following preamble:

Schema Definition:

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE schema  PUBLIC "-//W3C//DTD XMLSchema 200102//EN"
<!ATTLIST schema
xmlns:xenc CDATA #FIXED "http://www.w3.org/2001/04/xmlenc#"
xmlns:ds CDATA #FIXED "http://www.w3.org/2000/09/xmldsig#"
xmlns:xenc11 CDATA #FIXED "http://www.w3.org/2009/xmlenc11#">
<!ENTITY xenc "http://www.w3.org/2001/04/xmlenc#">
<!ENTITY % p "">
<!ENTITY % s "">
<schema xmlns="http://www.w3.org/2001/XMLSchema" version="1.0"
        xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
        xmlns:xenc11="http://www.w3.org/2009/xmlenc11#"
        xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
        targetNamespace="http://www.w3.org/2009/xmlenc11#"
        elementFormDefault="qualified">
  <import namespace="http://www.w3.org/2000/09/xmldsig#"
          schemaLocation="http://www.w3.org/TR/2002/
                          REC-xmldsig-core-20020212/xmldsig-core-schema.xsd"/>
  <import namespace="http://www.w3.org/2001/04/xmlenc#"
          schemaLocation="http://www.w3.org/TR/2002/
                          REC-xmlenc-core-20021210/xenc-schema.xsd"/>

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

3.1 The `EncryptedType` Element

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. Implementations MUST generate laxly schema valid [ XMLSCHEMA-1 ], [ XMLSCHEMA-2 ] EncryptedData or EncryptedKey elements as specified by the subsequent schema declarations. (Note the laxly schema valid generation means that the content permitted by xsd:ANY need not be valid.) Implementations SHOULD create these XML structures ( EncryptedType elements and their descendants/content) in Normalization Form C [ NFC ].

Schema Definition:

<complexType name="EncryptedType" abstract="true">
  <sequence>
    <element name="EncryptionMethod" type="xenc:EncryptionMethodType" 
             minOccurs="0"/>
    <element ref="ds:KeyInfo" minOccurs="0"/>
    <element ref="xenc:CipherData"/>
    <element ref="xenc:EncryptionProperties" minOccurs="0"/>
  </sequence>
  <attribute name="Id" type="ID" use="optional"/>
  <attribute name="Type" type="anyURI" use="optional"/>
  <attribute name="MimeType" type="string" use="optional"/>
  <attribute name="Encoding" type="anyURI" use="optional"/> 
</complexType>

EncryptionMethod is an optional element that describes the encryption algorithm applied to the cipher data. If the element is absent, the encryption algorithm must be known by the recipient or the decryption will fail.

ds:KeyInfo is an optional element, defined by [ XMLDSIG-CORE1 ], that carries information about the key used to encrypt the data. Subsequent sections of this specification define new elements that may appear as children of ds:KeyInfo .

CipherData is a mandatory element that contains the CipherValue or CipherReference with the encrypted data.

EncryptionProperties can contain additional information concerning the generation of the EncryptedType (e.g., date/time stamp).

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

Type is an optional attribute identifying type information about the plaintext form of the encrypted content. While optional, this specification takes advantage of it for processing described in section 4.4 Decryption . If the EncryptedData element contains data of Type 'element' or element 'content', and replaces that data in an XML document context, or contains data of Type 'EXI', 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 cleartext form.

MimeType is an optional (advisory) attribute which describes the media type of the data which has been encrypted. The value of this attribute is a string with values defined by [ RFC2045 ]. For example, if the data that is encrypted is a base64 encoded PNG, the transfer Encoding may be specified as ' http://www.w3.org/2000/09/xmldsig#base64 ' and the MimeType as 'image/png'. This attribute is purely advisory; no validation of the MimeType information is required and it does not indicate the encryption application must do any additional processing. Note, this information may not be necessary if it is already bound to the identifier in the Type attribute. For example, the Element and Content types defined in this specification are always UTF-8 encoded text. In the case of Type EXI the MimeType attribute is not necessary, but if used should reflect the underlying type and not "EXI".

Encoding is an optional (advisory) attribute which describes the transfer encoding of the data that has been encrypted.

3.2 The `EncryptionMethod` Element

EncryptionMethod is an optional element that describes the encryption algorithm applied to the cipher data. If the element is absent, the encryption algorithm must be known to the recipient or the decryption will fail.

Schema Definition:

<complexType name="Encryptionmethodtype" mixed="true">
  <sequence>
    <element name="KeySize" minOccurs="0" type="xenc:KeySizeType"/>
    <element name="OAEPparams" minOccurs="0" type="base64Binary"/>
    <any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
  </sequence>
  <attribute name="Algorithm" type="anyURI" use="required"/>
</complexType>

The permitted child elements of the EncryptionMethod are determined by the specific value of the Algorithm attribute URI, and the KeySize child element is always permitted. For example, the RSA-OAEP algorithm ( section 5.5.2 RSA-OAEP ) uses the ds:DigestMethod and OAEPparams elements, and may use the xenc11:MGF element when needed. (We rely upon the ANY schema construct because it is not possible to specify element content based on the value of an attribute.)

The presence of any child element under EncryptionMethod that is not permitted by the algorithm or the presence of a KeySize child inconsistent with the algorithm MUST be treated as an error. (All algorithm URIs specified in this document imply a key size but this is not true in general. Most popular stream cipher algorithms take variable size keys.)

3.3 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 as element content of the CipherValue element, or provide a reference to an external location containing the encrypted octet sequence via the CipherReference element.

Schema Definition:

<element name="CipherData" type="xenc:CipherDataType"/>
<complexType name="CipherDataType">
  <choice>
    <element name="CipherValue" type="base64Binary"/>
    <element ref="xenc:CipherReference"/>
  </choice>
</complexType>

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 Transform s, 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:

Example 13

<CipherReference URI="http://www.example.com/CipherValues.xml">
  <Transforms>
    <ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
      <ds:XPath xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
        self::text()[parent::enc:CipherValue[@Id="example1"]]
      </ds:XPath>
    </ds:Transform>
    <ds:Transform Algorithm="http://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>

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 element content, or serves as the new document root.

Schema Definition:

<element name="EncryptedData" type="xenc:EncryptedDataType"/>
<complexType name="EncryptedDataType">
  <complexContent>
    <extension base="xenc:EncryptedType">
    </extension>
  </complexContent>
</complexType>

3.5 Extensions to `ds:KeyInfo` Element

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

The


    EncryptedData


    EncryptedKey

element specify the associated keying material via a child of


    ds:KeyInfo

. All of the child elements of ds:


    KeyInfo

specified in [ XMLDSIG-CORE1 ] MAY be used as qualified:

Support for


    ds:KeyValue

is OPTIONAL and may be used to transport public keys, such as Diffie-Hellman Key Values ( section 5.6.1 Diffie-Hellman Key Values ). (Including the plaintext decryption key, whether a private key or a secret key, is obviously NOT RECOMMENDED .)

Support of


    ds:KeyName

to refer to an


    EncryptedKey


    CarriedKeyName

is RECOMMENDED .

Support for same document


    ds:RetrievalMethod

is REQUIRED .

In addition, we provide two additional child elements: applications MUST support EncryptedKey ( section 3.5.1 The EncryptedKey Element ) and MAY support AgreementMethod ( section 5.6 Key Agreement ).

A detached (not inside


    ds:KeyInfo

)


    EncryptedKey

element can specify the


    EncryptedData


    EncryptedKey

to which its decrypted key will apply via a


    DataReference


    KeyReference

( section 3.6 The ReferenceList Element ).

The keying material can be determined by the recipient by application context and thus need not be explicitly mentioned in the transmitted

3.5.1 The `EncryptedKey` Element

Identifier


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

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

The EncryptedKey element is used to transport encryption keys from the originator to a known recipient(s). It may be used as a stand-alone XML document, be placed within an application document, or appear inside an EncryptedData element as a child of a ds:KeyInfo element. The key value is always encrypted to the recipient(s). When EncryptedKey is decrypted the resulting octets are made available to the EncryptionMethod algorithm without any additional processing.

Schema Definition:

<element name="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="http://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


     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


     SignatureMethod

algorithm without any additional processing.

Schema Definition:

<!-- targetNamespace=&#x27;http://www.w3.org/2009/xmlenc11#&#x27; -->
<element name="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 
            'http://www.w3.org/2001/04/xmlenc#EncryptedKey' provides a way
            to express a link to an EncryptedKey element containing the key
            needed to decrypt the CipherData associated with an
            EncryptedData or EncryptedKey element. The ds:RetrievalMethod [XMLDSIG-CORE1] with a Type of 'http://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.
        3.6 The ReferenceList Element
        ReferenceList is an element that contains pointers from a key
          value of an EncryptedKey or DerivedKey to items encrypted by that key value
          (EncryptedData or EncryptedKey elements).
        Schema Definition:
<element name="ReferenceList">
  <complexType>
    <choice minOccurs="1" maxOccurs="unbounded">
      <element name="DataReference" type="xenc:ReferenceType"/>
      <element name="KeyReference" type="xenc:ReferenceType"/>
    </choice>
  </complexType>
</element>
<complexType name="ReferenceType">
  <sequence>
    <any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
  </sequence>
  <attribute name="URI" type="anyURI" use="required"/>
</complexType>
        DataReference elements are used to refer to
          EncryptedData elements that were encrypted using the key defined
          in the enclosing EncryptedKey or DerivedKey element. Multiple
          DataReference elements can occur if multiple
          EncryptedData elements exist that are encrypted by the same
        
KeyReference elements are used to refer to
          EncryptedKey elements that were encrypted using the key defined
          in the enclosing EncryptedKey or DerivedKey element. Multiple
          KeyReference elements can occur if multiple
          EncryptedKey elements exist that are encrypted by the same
        
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 elements from a document storage facility. For example:
        Example 14




    
<ReferenceList>
  <DataReference URI="#invoice34">
    <ds:Transforms>
      <ds:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
        <ds:XPath xmlns:xenc="http://www.w3.org/2001/04/xmlenc#">
          self::xenc:EncryptedData[@Id="example1"]
        </ds:XPath>
      </ds:Transform>
    </ds:Transforms>
  </DataReference>
</ReferenceList>
        3.7 The EncryptionProperties Element
          Identifier
          Type="http://www.w3.org/2001/04/xmlenc#EncryptionProperties" 
            (This can be used within a ds:Reference element to
              identify the referent's type.)
        Additional information items concerning the generation of the
          EncryptedData or EncryptedKey can be placed in an
          EncryptionProperty element (e.g., date/time stamp or the serial
          number of cryptographic hardware used during encryption). The
          Target attribute identifies the EncryptedType
          structure being described. anyAttribute permits the inclusion of
          attributes from the XML namespace to be included (i.e.,
          xml:space, xml:lang, and xml:base).
        Schema Definition:
<element name="EncryptionProperties" type="xenc:EncryptionPropertiesType"/> 
<complexType name="EncryptionPropertiesType">
  <sequence>
    <element ref="xenc:EncryptionProperty" maxOccurs="unbounded"/> 
  </sequence>
  <attribute name="Id" type="ID" use="optional"/> 
</complexType>
<element name="EncryptionProperty" type="xenc:EncryptionPropertyType"/> 
<complexType name="EncryptionPropertyType" mixed="true">
  <choice maxOccurs="unbounded">
    <any namespace="##other" processContents="lax"/>
  </choice>
  <attribute name="Target" type="anyURI" use="optional"/> 
  <attribute name="Id" type="ID" use="optional"/> 
  <anyAttribute namespace="http://www.w3.org/XML/1998/namespace"/>
</complexType>
      This section describes the operations to be performed as part of
        encryption and decryption processing by implementations of this
        specification. The conformance requirements are specified over the following
        roles:




    

        Encryptor
        An XML Encryption implementation with the role of encrypting
          data.
        Decryptor
        An XML Encryption implementation with the role of decrypting
          data.
      Encryptor and Decryptor are invoked by the Application.  This specification does not include normative definitions for application behavior.  However, this specification does include conformance requirements on encrypted data that may only be achievable through appropriate behavior by all three parties.  It is up to specific deployment contexts how this is achieved.
        4.1 Intended Application Model
        The processing rules for XML Encryption are designed around an intended application model that this version of the specification does not cover normatively.
        In the intended processing model, XML Encryption is used to encrypt
          an octet-stream, an EXI stream, or a fragment of an XML document that
          matches either the content or element
          production from [XML10].
        If XML Encryption is used with some octet-stream, the precise encoding and meaning of that octet-stream is up to the application, but treated as opaque by the Encryptor or Decryptor.  The application may use the Type, Encoding and MimeType parameters to transport further information about the nature of that octet-stream. Hence, an unknown Type parameter is, in general, not treated as an error by either the Encryptor or Decryptor, but instead simply passed through, along with the other relevant parameters and the cleartext octet-stream.
        If XML Encryption is used with an XML element or XML content, then Encryptors and Decryptors commonly perform type-specific processing:
          If an element is encrypted, then the Encryptor
            will replace the element in question with an appropriately
            constructed EncryptedData element.  The Decryptor
            will, conversely, replace the EncryptedData element
            with its cleartext. 
          If XML content is encrypted, then the Encryptor will likewise replace this content with an appropriately constructed EncryptedData element, and the Decryptor will reverse this operation.
        Note that the intended Encryptor behavior 
          will often cause the document with encrypted parts to become
          invalid with respect to its schema
          the hosting XML format, unless that format is specifically prepared
          to be used with XML Encryption.  An Encryptor or Decryptor that
          implements the intended processing model is NOT REQUIRED to ensure
          that the resulting XML is schema-valid for the hosting XML
          format. 
        If XML processing is handled inside the Encryptor and Decryptor, and the Type attribute values for element and content cleartext are used, then the Encryptor and Decryptor MUST ensure that the XML cleartext is serialized as UTF-8 before encryption, and -- if needed -- converted back to whatever other encoding might be used by the surrounding XML context.
        If XML Encryption is used with an EXI stream [EXI], then Encryptors and
          Decryptors process content as for XML element or XML content processing, but taking into account EXI serialization. In particular,
          the encryptor will replace the XML element or XML fragment in question
          with an appropriately constructed EncryptedData element. The Decryptor
          will conversely replace the EncryptedData element with its cleartext
          XML element or XML fragment. Note that the XML document into which the
          EncryptedData element is embedded may be encoded using EXI and/or EXI
          may be used to encode the cleartext before encryption.  
        4.2 Well-known Type parameter values
        For interoperability purposes, the following types MUST be implemented
          such that an implementation will be able to take as input and yield as output
          data matching the production rules 39 and 43 from [XML10]:
          element 'http://www.w3.org/2001/04/xmlenc#Element'
          "[39]  element
            ::= EmptyElemTag
            | STag
            content
            ETag"
          content 'http://www.w3.org/2001/04/xmlenc#Content'
          "[43] content
            ::= CharData?
            ((element
            | Reference
            | CDSect
            | PI |
            Comment)
            CharData?)*"
        Support for the following type is OPTIONAL for Encryptors and Decryptors:
          http://www.w3.org/2009/xmlenc11#EXI
          Presence of this Type indicates that the cleartext is an EXI stream [EXI].  Encryptors and Decryptors that support this type MAY operate directly on (parts of) EXI streams.
        Encryptors and Decryptors SHOULD handle unknown or empty Type attribute values as a signal that the cleartext is to be handled as an opaque octet-stream, whose specific processing is up to the invoking application. In this case, the Type, MimeType and Encoding parameters SHOULD be treated as opaque data whose appropriate processing is up to the application.
        4.3 Encryption
        The selection of the algorithm, parameters, and encryption keys is out of scope for this specification.
        The cleartext data are assumed to be present as an octet stream.  If the cleartext is of type element or content, the data MUST be serialized in UTF-8 as specified in [XML10], using Normal Form C [NFC].
        For each data item to be encrypted as an EncryptedData or
          EncryptedKey element, the encryptor MUST:
          Obtain (or derive) and (optionally) represent the key. 
              
If the key is to be identified (via naming, URI, or included in a
                  child element), construct the ds:KeyInfo as appropriate
                  (e.g., ds:KeyName, ds:KeyValue,
                  ds:RetrievalMethod, etc.)
              If the key itself is to be encrypted, construct an
                  EncryptedKey element by recursively applying this
                  encryption process. The result may then be a child of
                  ds:KeyInfo, or it may exist elsewhere and may be
                  identified in the preceding step.
              If the key was derived from a master key, construct a
                  DerivedKey element with associated child
                  elements. The result may, as in the EncryptedKey
                  case, be a child of ds:KeyInfo, or it may exist
                  elsewhere.
          Encrypt the data:
              
Encrypt the octets using the algorithm and key.
                Unless the decryptor will implicitly know the type of the
                  encrypted data, the encryptor SHOULD set the
                  Type to indicate the intended interpretation of the cleartext
                  data. See section 4.2 Well-known Type parameter values
                  for known parameter values.
                If the data is a
                  simple octet sequence it MAY be described with the
                  MimeType and Encoding attributes. For
                  example, the data might be an XML document
                  (MimeType="text/xml"), sequence of characters
                  (MimeType="text/plain"), or binary image data
                  (MimeType="image/png").
          Build the EncryptedData or
            EncryptedKey structure: 
            An EncryptedData or EncryptedKey structure represents all of the
              information previously discussed including the type of the encrypted
              data, encryption algorithm, parameters, key, type of the encrypted data,
              
If the encrypted octet sequence obtained in step 2 is to be stored
                in the CipherData element within the
                EncryptedData or EncryptedKey element, then the base64 representation of the encrypted octet sequence is
                inserted as the content of a
                CipherValue element.
              If the encrypted octet sequence is stored externally to the
                  EncryptedData or EncryptedKey element, 
                  then  the URI and transforms (if
                  any) required for the Decryptor to retrieve the encrypted octet
                  sequence are described within a 
                  CipherReference element.
          
Determine the algorithm, parameters and key information to be used.
            This information may be obtained out-of-band, or determined according to
            a ds:KeyInfo element;
            see section 3.5 Extensions to ds:KeyInfo Element.
          
Decrypt the data contained in the CipherData element. 
                
If a CipherValue child element is present, then the
                    associated text value is retrieved and base64 decoded so as to obtain
                    the encrypted octet sequence.
                If a CipherReference child element is present, the URI
                    and transforms (if any) are used to retrieve the encrypted octet
                    sequence.
                The encrypted octet sequence is decrypted using the
                    algorithm, parameters and key value already determined from step 1.
        Encryption and decryption operations are operations on octets. The
          application is responsible for the marshalling XML such that
          it can be serialized into an octet sequence, encrypted, decrypted, and be of
          use to the recipient.
        For example, if the application wishes to canonicalize its data or
          encode/compress the data in an XML packaging format, the application needs to
          marshal the XML accordingly and identify the resulting type via the
          EncryptedData Type attribute. The likelihood of
          successful decryption and subsequent processing will be dependent on the
          recipient's support for the given type. Also, if the data is intended to be
          processed both before encryption and after decryption (e.g., XML Signature
          [XMLDSIG-CORE1] validation or an XSLT transform) the
          encrypting application must be careful to preserve information necessary for
          that process's success.
        The following sections contain specifications for decrypting, replacing,
          and serializing XML content (i.e., Type 'element' or
          element 'content')
          using the [XPATH] data model. These sections are
          non-normative and OPTIONAL to implementers of this specification, but they
          may be normatively referenced by and be required by other specifications that
          require a consistent processing for applications, such as [XMLENC-DECRYPT].
          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:
            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
                
Name and value of each general entity that is effective for the XML
                  document causing P.
            Wrap the decrypted octet stream O in the context C as
              specified in section 4.5.4 Text Wrapping.
            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.
            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.
            Z is an [XPATH] node-set that
              identical to X except where the element node e is an
              EncryptedData element type. In which case: 
                
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. 
                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.
            In section 4.3 Encryption
              (step 3.1), when serializing an XML fragment special 
              care SHOULD be taken with respect to default namespaces. If the data will be
              subsequently decrypted in the context of a parent XML document then
              serialization can produce elements in the wrong namespace. Consider the
              following fragment of XML:
            Example 15




    
<Document xmlns="http://example.org/">
  <ToBeEncrypted xmlns="" />
</Document>
            Serialization of the element ToBeEncrypted fragment via [XML-C14N] would result in the characters
              "<ToBeEncrypted></ToBeEncrypted>" as an octet
              stream. The resulting encrypted document would be:
            Example 16
<Document xmlns="http://example.org/">
  <EncryptedData xmlns="...">
    <!-- Containing the encrypted "<ToBeEncrypted></ToBeEncrypted>" -->
  </EncryptedData>
</Document>
            Decrypting and replacing the EncryptedData within this
              document would produce the following incorrect result:
            Example 17
<Document xmlns="http://example.org/">
  <ToBeEncrypted/>
</Document> 
            This problem arises because most XML serializations assume that the
              serialized data will be parsed directly in a context where there is no
              default namespace declaration. Consequently, they do not redundantly declare
              the empty default namespace with an xmlns="". If, however, the
              serialized data is parsed in a context where a default namespace declaration
              is in scope (e.g., the parsing context as described in section 4.5.1 A Decrypt
            Implementation (Non-normative)), then
              it may affect the interpretation of the serialized data.
            To solve this problem, a canonicalization algorithm MAY be augmented as
              follows for use as an XML encryption serializer:
              A default namespace declaration with an empty value (i.e.,
                xmlns="") SHOULD be emitted where it would normally be
                suppressed by the canonicalization algorithm.
            While the result may not be in proper canonical form, this is harmless as
              the resulting octet stream will not be used directly in a
              [XMLDSIG-CORE1] signature value computation. 
              Returning to the preceding example with our new augmentation, the
              ToBeEncrypted element would be serialized as follows:
            <ToBeEncrypted xmlns=""></ToBeEncrypted>
            When processed in the context of the parent document, this serialized
              fragment will be parsed and interpreted correctly.
            This augmentation can be retroactively applied to an existing
              canonicalization implementation by canonicalizing each apex node and its
              descendants from the node set, inserting xmlns="" at the
              appropriate points, and concatenating the resulting octet streams.
            4.5.3.2 XML Attribute Considerations
            Similar attention between the relationship of a fragment and the context
              into which it is being inserted should be given to the xml:base,
              xml:lang, and xml:space attributes as mentioned in
              the Security
                Considerations of [XML-EXC-C14N]. For
              example, if the element:
            Example 18
<Bongo href="example.xml"/>
            is taken from a context and serialized with no xml:base [XMLBASE] attribute and parsed in the context of the
              element:
            Example 19
<Baz xml:base="http://example.org/"/>
            the result will be:
            Example 20
<Baz xml:base="http://example.org/"><Bongo href="example.xml"/></Baz>
            Bongo's href is subsequently interpreted as
              "http://example.org/example.xml". If this is not the correct
              URI, Bongo should have been serialized with its own
              xml:base attribute.
            Unfortunately, the recommendation that an empty value be emitted to
              divorce the default namespace of the fragment from the context into which it
              is being inserted cannot be made for the attributes
                xml:base, and xml:space. (Error 41 of the XML 1.0 Second Edition
                  Specification Errata clarifies that an empty string value of the
                attribute xml:lang is considered as if, "there is no
                language information available, just as if xml:lang had not been
                specified".)The interpretation of an empty value for the
              xml:base or xml:space attributes is undefined or
              maintains the contextual value. Consequently, applications SHOULD ensure (1)
              fragments that are to be encrypted are not dependent on XML attributes, or
              (2) if they are dependent and the resulting document is intended to be valid [XML10], the fragment's definition permits the presence of
              the attributes and that the attributes have non-empty values.
          4.5.4 Text Wrapping
          This section specifies the process for wrapping text in a given parsing
            context. The process is based on the proposal by Richard Tobin [Tobin] for constructing the infoset [XML-INFOSET] of an external entity.
          The process consists of the following steps:
            If the parsing context contains any general entities, then emit a
                document type declaration that provides entity declarations.
            Emit a dummy element start-tag with namespace declaration
                attributes declaring all the namespaces in the parsing context.
            Emit the text.
            Emit a dummy element end-tag.
          In the above steps, the document type declaration and dummy
            element tags MUST be encoded in UTF-8.
          Consider the following document containing an EncryptedData
            element:
          Example 21
<!DOCTYPE Document [
<!ENTITY dsig "http://www.w3.org/2000/09/xmldsig#">
<Document xmlns="http://example.org/">
  <foo:Body xmlns:foo="http://example.org/foo">
    <EncryptedData xmlns="http://www.w3.org/2001/04/xmlenc#"
                   Type="http://www.w3.org/2001/04/xmlenc#Element">
    </EncryptedData> 
  </foo:Body>
</Document>
          If the EncryptedData element is decrypted to
            the text "<One><foo:Two/></One>", then the
            wrapped form is as follows:
          Example 22
<!DOCTYPE dummy [
<!ENTITY dsig "http://www.w3.org/2000/09/xmldsig#">
<dummy xmlns="http://example.org/"
       xmlns:foo="http://example.org/foo">
    <foo:Two/>
</dummy>
      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 element representing the role of the algorithm, a reference to the
        formal specification, definitions for the representation of keys and the
        results of cryptographic operations where applicable, and general
        applicability comments.
        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. Levels of requirement specified, such as
          "REQUIRED" or "OPTIONAL", refer to implementation, not use. Furthermore, the
          mechanism is extensible, and alternative algorithms may be used.
          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
                REQUIRED TRIPLEDES

                  http://www.w3.org/2001/04/xmlenc#tripledes-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
                REQUIRED AES128-GCM

                  http://www.w3.org/2009/xmlenc11#aes128-gcm
                OPTIONAL AES-192

                  http://www.w3.org/2001/04/xmlenc#aes192-cbc
                OPTIONAL AES192-GCM

                  http://www.w3.org/2009/xmlenc11#aes192-gcm
                OPTIONAL AES256-GCM

                  http://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
                  Syntax and recommendations are given below to support user
                  specified algorithms.

Key Derivation

REQUIRED ConcatKDF
http://www.w3.org/2009/xmlenc11#ConcatKDF

OPTIONAL PBKDF2
http://www.w3.org/2009/xmlenc11#pbkdf2

Key Transport

REQUIRED RSA-OAEP (including MGF1 with SHA1)
http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p

Optional RSA-OAEP
http://www.w3.org/2009/xmlenc11#rsa-oaep

OPTIONAL RSA-v1.5 (see RSA-v1.5 security note )
http://www.w3.org/2001/04/xmlenc#rsa-1_5

Key Agreement

REQUIRED Elliptic Curve Diffie-Hellman (Ephemeral-Static mode)
http://www.w3.org/2009/xmlenc11#ECDH-ES

OPTIONAL Diffie-Hellman Key Agreement (Ephemeral-Static mode) with Legacy Key Derivation Function
http://www.w3.org/2001/04/xmlenc#dh

OPTIONAL Diffie-Hellman Key Agreement (Ephemeral-Static mode) with explicit Key Derivation Functions
http://www.w3.org/2009/xmlenc11#dh-es

Symmetric Key Wrap

REQUIRED TRIPLEDES KeyWrap
http://www.w3.org/2001/04/xmlenc#kw-tripledes

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

REQUIRED SHA1 ( Use is DISCOURAGED ; see below).
http://www.w3.org/2000/09/xmldsig#sha1

REQUIRED SHA256
http://www.w3.org/2001/04/xmlenc#sha256

OPTIONAL SHA384
http://www.w3.org/2001/04/xmlenc#sha384

OPTIONAL SHA512
http://www.w3.org/2001/04/xmlenc#sha512

OPTIONAL RIPEMD-160
http://www.w3.org/2001/04/xmlenc#ripemd160

Canonicalization

OPTIONAL Canonical XML 1.0 (omit comments)
http://www.w3.org/TR/2001/REC-xml-c14n-20010315

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

OPTIONAL Canonical XML 1.1 (omit comments)
http://www.w3.org/2006/12/xml-c14n11

OPTIONAL Canonical XML 1.1 (with comments)
http://www.w3.org/2006/12/xml-c14n11#WithComments

OPTIONAL Exclusive XML Canonicalization 1.0 (omit comments)
http://www.w3.org/2001/10/xml-exc-c14n#

OPTIONAL Exclusive XML Canonicalization 1.0 (with comments)
http://www.w3.org/2001/10/xml-exc-c14n#WithComments

Encoding

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

Transforms

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

*note: The same URI is used to identify base64 both in "encoding" context (e.g. when used with the Encoding attribute of an EncryptedKey element, see section 3.1 The EncryptedType Element ) as well as in "transform" context (when identifying a base64 transform for a CipherReference , see section 3.3.1 The CipherReference Element ).

5.2 Block Encryption Algorithms

Block encryption algorithms are designed for encrypting and decrypting data in fixed size, multiple octet blocks. Their identifiers appear as the value of the Algorithm attributes of EncryptionMethod elements that are children of EncryptedData .

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

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

The IV is encoded with and before the cipher text 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 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:

http://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:

Example 23

<EncryptionMethod Algorithm="http://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:

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

[ 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:

Example 24

<EncryptionMethod Algorithm="http://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:

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

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

http://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.3 Stream Encryption Algorithms

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

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

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

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

Schema Definition:

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

5.4 Key Derivation

Key derivation is a well-established mechanism for generating new cryptographic key material from some existing, original ("master") key material and potentially other information. Derived keys are used for a variety of purposes including data encryption and message authentication. The reason for doing key derivation itself is typically a combination of a desire to expand a given, but limited, set of original key material and prudent security practices of limiting use (exposure) of such key material. Key separation (such as avoiding use of the same key material for multiple purposes) is an example of such practices. The key derivation process may be based on passphrases agreed upon or remembered by users, or it can be based on some shared "master" cryptographic keys (and be intended to reduce exposure of such master keys), etc. Derived keys themselves may be used in XML Signature and XML Encryption as any other keys; in particular, they may be used to compute message authentication codes (e.g. digital signatures using symmetric keys) or for encryption/decryption purposes.

5.4.1 ConcatKDF

Identifier:

http://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;http://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
            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:
                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
                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.
                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:
          
Example 25
<xenc11:DerivedKey
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
    xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
    xmlns:xenc11="http://www.w3.org/2009/xmlenc11#">
  <xenc11:KeyDerivationMethod Algorithm="http://www.w3.org/2009/xmlenc11#ConcatKDF">
    <xenc11:ConcatKDFParams AlgorithmID="0000" PartyUInfo="03D8" PartyVInfo="03D0"> 
      <ds:DigestMethod Algorithm="http://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>
            While any bit string can be used with ConcatKDF, it is RECOMMENDED to keep byte
            aligned for greatest interoperability.
          5.4.2 PBKDF2
            Identifier:
            http://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:
            
Example 26




    
<xenc11:DerivedKey
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
    xmlns:xenc11="http://www.w3.org/2009/xmlenc11#">
  <xenc11:KeyDerivationMethod Algorithm="http://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="http://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 Key Transport
        Key Transport algorithms are public key encryption algorithms especially
          specified for encrypting and decrypting keys. Their identifiers appear as
          Algorithm attributes to EncryptionMethod elements
          that are children of EncryptedKey. EncryptedKey is
          in turn the child of a ds:KeyInfo element. The type of key being
          transported, that is to say the algorithm in which it is planned to use the
          transported key, is given by the Algorithm attribute of the
          EncryptionMethod child of the EncryptedData or
          EncryptedKey parent of this ds:KeyInfo element.
        (Key Transport algorithms may optionally be used to encrypt data in which
          case they appear directly as the Algorithm attribute of an
          EncryptionMethod child of an EncryptedData element.
          Because they use public key algorithms directly, Key Transport algorithms are
          not efficient for the transport of any amounts of data significantly larger
          than symmetric keys.)
          5.5.1 RSA Version 1.5
            Identifier:
            http://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:
          Example 27
<EncryptionMethod Algorithm="http://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:
          Example 28
CRYPT ( PAD ( KEY ))
          where the padding is of the following special form:
          Example 29
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.
          Example 30
<CipherData>
  <CipherValue>IWijxQjUrcXBYoCei4QxjWo9Kg8D3p9tlWoT4
t0/gyTE96639In0FZFY2/rvP+/bMJ01EArmKZsR5VW3rwoPxw=</CipherValue>
</CipherData>
          (Note: A newline has been added to the CipherValue
          to fit on this page, but is not part of value.) 
            Note: Implementation of RSA v1.5 is NOT RECOMMENDED due
              to security risks associated with the algorithm. 
          5.5.2 RSA-OAEP
            
Identifier:
            http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p
              (including MGF1 with SHA1 mask generation function)
            Identifier:
            http://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 http://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 http://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: http://www.w3.org/2009/xmlenc11#mgf1sha1
            MGF1 with SHA224: http://www.w3.org/2009/xmlenc11#mgf1sha224
            MGF1 with SHA256: http://www.w3.org/2009/xmlenc11#mgf1sha256
            MGF1 with SHA384: http://www.w3.org/2009/xmlenc11#mgf1sha384
            MGF1 with SHA512: http://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:
          Example 31
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
  <OAEPparams>9lWu3Q==</OAEPparams>
  <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<EncryptionMethod>
          Example 32
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p">
            <OAEPparams>9lWu3Q==</OAEPparams>
            <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
            <EncryptionMethod>
          Another example is:
          Example 33
<EncryptionMethod Algorithm="http://www.w3.org/2009/xmlenc11#rsa-oaep">
  <OAEPparams>9lWu3Q==</OAEPparams>
  <xenc11:MGF Algorithm="http://www.w3.org/2001/04/xmlenc#MGF1withSHA1" />
  <ds:DigestMethod Algorithm="http://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 Key Agreement
        A Key Agreement algorithm provides for the derivation of a shared secret
          key based on a shared secret computed from certain types of compatible public
          keys from both the sender and the recipient. Information from the originator
          to determine the secret is indicated by an optional
          OriginatorKeyInfo parameter child of an
          AgreementMethod element while that associated with the recipient
          is indicated by an optional RecipientKeyInfo. A shared key is
          derived from this shared secret by a method determined by the Key Agreement
          algorithm.
        Note: XML Encryption does not provide an online key agreement negotiation
          protocol. The AgreementMethod element can be used by the
          originator to identify the keys and computational procedure that were used to
          obtain a shared encryption key. The method used to obtain or select the keys
          or algorithm used for the agreement computation is beyond the scope of this
          specification.
        The AgreementMethod element appears as the content of a
          ds:KeyInfo since, like other ds:KeyInfo children,
          it yields a key. This ds:KeyInfo is in turn a child of an
          EncryptedData or EncryptedKey element. The
          Algorithm attribute and KeySize child of the
          EncryptionMethod element under this EncryptedData
          or EncryptedKey element are implicit parameters to the key
          agreement computation. In cases where this EncryptionMethod
          algorithm URI is insufficient to determine the key length, a
          KeySize MUST have been included.
          Key derivation algorithms (with associated parameters) may be
          explicitly declared by using the
          xenc11:KeyDerivationMethod element. This element will
          then be placed at the extensibility point of the
          xenc:AgreementMethodType (see below).
          In addition, the sender may place a KA-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: 
        Example 34
<EncryptedData>
  <EncryptionMethod Algorithm="Example:Block/Alg">
    <KeySize>80</KeySize>
  </EncryptionMethod>
  <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
    <AgreementMethod Algorithm="example:Agreement/Algorithm">
      <KA-Nonce>Zm9v</KA-Nonce>
      <xenc11:KeyDerivationMethod
          Algorithm="http://www.w3.org/2009/xmlenc11#ConcatKDF">
        <xenc11:ConcatKDFParams 
            AlgorithmID="00" PartyUInfo="" PartyVInfo=""> 
          <ds:DigestMethod 
              Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
        </xenc11:ConcatKDFParams>
      </xenc11:KeyDerivationMethod>
      <OriginatorKeyInfo>
        <ds:KeyValue>....</ds:KeyValue>
      </OriginatorKeyInfo>
      <RecipientKeyInfo>
        <ds:KeyValue>....</ds:KeyValue>
      </RecipientKeyInfo> 
    </AgreementMethod>
  </ds:KeyInfo>
  <CipherData>...</CipherData>
</EncryptedData>
        If the agreed key is being used to wrap a key, rather than data as above,
          then AgreementMethod would appear inside a
          ds:KeyInfo inside an EncryptedKey element.
        The Schema for AgreementMethod is as follows:
        Schema Definition:
<element name="AgreementMethod" type="xenc:AgreementMethodType"/>
<complexType name="AgreementMethodType" mixed="true">
  <sequence>
    <element name="KA-Nonce" minOccurs="0" type="base64Binary"/>
    <!-- <element ref="ds:DigestMethod" minOccurs="0"/> -->
    <any namespace="##other" minOccurs="0" maxOccurs="unbounded"/>
    <element name="OriginatorKeyInfo" minOccurs="0" 
             type="ds:KeyInfoType"/>
    <element name="RecipientKeyInfo" minOccurs="0" 
             type="ds:KeyInfoType"/>
  </sequence>
  <attribute name="Algorithm" type="anyURI" use="required"/>
</complexType>
          5.6.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.
          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:
          Example 35




    
<AgreementMethod
    Algorithm="http://www.w3.org/2001/04/xmlenc#dh"
    ds:xmlns="http://www.w3.org/2000/09/xmldsig#">
  <KA-Nonce>Zm9v</KA-Nonce>
  <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
  <OriginatorKeyInfo>
    <ds:X509Data>
      <ds:X509Certificate>...</ds:X509Certificate>
    </ds:X509Data>
  </OriginatorKeyInfo>
  <RecipientKeyInfo>
    <ds:KeyValue>...</ds:KeyValue>
  </RecipientKeyInfo>
</AgreementMethod>
            5.6.2.1 Diffie-Hellman Key Agreement with Explicit Key Derivation Functions
              
Identifier:
              http://www.w3.org/2009/xmlenc11#dh-es 
            It is RECOMMENDED that the shared key material for a Diffie-Hellman key agreement be calculated from the Diffie-Hellman shared secret 
              using a key derivation function (KDF) in accordance with Section 5.4.
              An example of a DH AgreementMethod element using an
              explicit key derivation function is as follows:
            
Example 36
<xenc:AgreementMethod Algorithm="http://www.w3.org/2009/xmlenc11#dh-es">
  <xenc11:KeyDerivationMethod Algorithm="http://www.w3.org/2009/xmlenc11#ConcatKDF">
    <xenc11:ConcatKDFParams AlgorithmID="00" PartyUInfo="" PartyVInfo=""> 
      <ds:DigestMethod Algorithm="http://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>
            5.6.2.2 Diffie-Hellman Key Agreement with Legacy Key Derivation Function
              Identifier:
              http://www.w3.org/2001/04/xmlenc#dh
            XML Signature 1.0 defined a specific KDF for use with Diffie-Hellman key agreement.  In order to guarantee interoperability, 
              implementations that choose to implement Diffie-Hellman MUST support the use of the Diffie-Hellman Legacy KDF defined in this section.
            
Assume that the Diffie-Hellman shared secret is the octet sequence
              ZZ. The Diffie-Hellman Legacy KDF calculates the shared keying material as follows:
            Example 37
Keying Material = KM(1) | KM(2) | ...
            where "|" is byte stream concatenation and
            Example 38
KM(counter) = DigestAlg ( ZZ | counter | EncryptionAlg |
            KA-Nonce | KeySize )
              
DigestAlg
              The message digest algorithm specified by the
                DigestMethod child of AgreementMethod.
              EncryptionAlg
              The URI of the encryption algorithm, including possible key wrap
                algorithms, in which the derived keying material is to be used
                ("Example:Block/Alg" in the example above), not the URI of the
                agreement algorithm. This is the value of the Algorithm
                attribute of the EncryptionMethod child of the
                EncryptedData or EncryptedKey grandparent of
                AgreementMethod.
              KA-Nonce
              The base64 decoding the content of the KA-Nonce child of
                AgreementMethod, if present. If the KA-Nonce
                element is absent, it is null.
              Counter
              A one byte counter starting at one and incrementing by one. It is
                expressed as two hex digits where letters A through F are in upper
                case.
              KeySize
              The size in bits of the key to be derived from the shared secret as
                the UTF-8 string for the corresponding decimal integer with only digits
                in the string and no leading zeros. For some algorithms the key size is
                inherent in the URI. For others, such as most stream ciphers, it must
                be explicitly provided.
            For example, the initial (KM(1)) calculation for the
              EncryptionMethod of the Key
                Agreement example (section 5.5) would be as follows, where the binary one
              byte counter value of 1 is represented by the two character UTF-8 sequence
              01, ZZ is the shared secret, and "foo"
              is the base64 decoding of "Zm9v".
            Example 39
SHA-1 ( ZZ01Example:Block/Algfoo80 )
            Assuming that ZZ is 0xDEADBEEF, that would be
            Example 40
SHA-1( 0xDEADBEEF30314578616D706C653A426C6F636B2F416C67666F6F3830 )
            whose value is
            Example 41
0x534C9B8C4ABDCB50038B42015A181711068B08C1
            Each application of DigestAlg for successive values of
              Counter will produce some additional number of bytes of keying
              material. From the concatenated string of one or more KM's,
              enough leading bytes are taken to meet the need for an actual key and the
              remainder discarded. For example, if DigestAlg is SHA-1 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.
          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:
            http://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:
          Example 42
<xenc:EncryptedData
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
    xmlns:ds="http://www.w3.org/2000/09/xmldsig#"
    xmlns:dsig11="http://www.w3.org/2009/xmldsig11#"
    xmlns:xenc11="http://www.w3.org/2009/xmlenc11#"
    Type="http://www.w3.org/2001/04/xmlenc#">
  <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#aes128-cbc" />
  <!-- describes the encrypted AES content encryption key -->
  <ds:KeyInfo>
    <xenc:EncryptedKey>
      <xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-aes128"/>
      <!-- describes the key encryption key -->
      <ds:KeyInfo>
        <xenc:AgreementMethod Algorithm="http://www.w3.org/2009/xmlenc11#ECDH-ES">
          <xenc11:KeyDerivationMethod Algorithm="http://www.w3.org/2009/xmlenc11#ConcatKDF">
            <xenc11:ConcatKDFParams AlgorithmID="00" PartyUInfo="" PartyVInfo=""> 
              <ds:DigestMethod Algorithm="http://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>




    

          Symmetric Key Wrap algorithms are shared secret key encryption  
          algorithms especially specified for encrypting and decrypting  
          symmetric keys.  When wrapped keys are used, then an EncryptedKey  
          element will appear as a child of a ds:KeyInfo element.  This  
          EncryptedKey element will have
          an EncryptionMethod child whose   
          Algorithm attribute in turn identifies the key wrap algorithm.
          The algorithm for which the encrypted key is intended depends on the  
          context of the ds:KeyInfo
          element:  ds:KeyInfo can occur as a child   
          of either an EncryptedData or EncryptedKey
          element; in both cases,   
          ds:KeyInfo will have an EncryptionMethod sibling that
          identifies the   
          algorithm.
        Example 43
<EncryptedData |EncryptedKey>
  <EncryptionMethod Algorithm="@alg1"/>
  <ds:KeyInfo>
    <EncryptedKey>
      <EncryptionMethod Algorithm="@alg2"/>
    </EncryptedKey>
  </ds:KeyInfo>
</EncryptedData |EncryptedKey>
          5.7.1 CMS Triple DES Key Wrap
            
Identifiers:
            http://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:
          Example 44
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-tripledes" />
          5.7.2 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 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.
        Message digest algorithms can be used in
          AgreementMethod as part of the key derivation, within
          RSA-OAEP encryption as a hash function, and in connection with the
          HMAC message authentication code method [HMAC]
          as described in [XMLDSIG-CORE1].) Use of SHA-256 is strongly
          recommended over SHA-1 because recent advances in cryptanalysis (see
          e.g. [SHA-1-Analysis], [SHA-1-Collisions] )
          have cast doubt on the long-term collision resistance of SHA-1.
          Therefore, SHA-1 support is REQUIRED in this specification only for
          backwards-compatibility reasons.
          5.8.1 SHA1
            Identifier:
            http://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:
          Example 45
<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:
          Example 46
A9993E36 4706816A BA3E2571 7850C26C 9CD0D89D
          from Appendix A of the SHA-1 standard would be:
          Example 47
<DigestValue>qZk+NkcGgWq6PiVxeFDCbJzQ2J0=</DigestValue>
          5.8.2 SHA256
            
Identifier:
            http://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:
          Example 48
<DigestMethod Algorithm="http://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:
            http://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:
          Example 49
<DigestMethod Algorithm="http://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:
            http://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:
          Example 50
<DigestMethod Algorithm="http://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:
            http://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:
          Example 51
<DigestMethod Algorithm="http://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 Canonicalization
        A Canonicalization of XML is a method of consistently serializing XML into
          an octet stream as is necessary prior to encrypting XML.
          5.9.1 Inclusive
            Canonicalization
            
Identifiers:
            http://www.w3.org/TR/2001/REC-xml-c14n-20010315
            
http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments
            
http://www.w3.org/2006/12/xml-c14n11
            
http://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:
            http://www.w3.org/2001/10/xml-exc-c14n#
            
http://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 Chosen-Ciphertext Attacks
          A number of chosen-ciphertext attacks against implementations of this
          specification have been published and demonstrated. They all
          involve the following elements:  
          The attacker knows about the format of the
            cleartext.
          The attacker is able to submit substantial numbers of ciphertext messages.
          The attacker is able to send arbitrary ciphertext, based on previous results.
          The attacker is able to force the server to use the same key
            (secret key by CBC-based attacks and server's private key by PKCS#1.5
            attacks) for processing of the adapted ciphertext.
          The server attempting to decrypt the ciphertext in some way
            signals whether the decrypted text is well-formed or
          The attacker uses the knowledge of the format and the information
          about well-formedness to construct a series of ciphertext
          guesses which reveal the plaintext with much less work than
          brute force. Attacks of this type have been demonstrated against
          symmetric encryption using CBC mode [XMLENC-CBC-ATTACK][XMLENC-CBC-ATTACK-COUNTERMEASURES] and on
          PKCS#1 v1.5. Other future attacks can be expected whenever
          these conditions are met. 
          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:
            
Observing fault messages of the server notifying directly that
              the request was not PKCS#1.5 conformant (this should not happen).
            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.
            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]: 
            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.
            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.
            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:
              Implementations SHOULD always use a different public key pair for data
              confidentiality and for data integrity functionality.
            
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.
            
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.
            
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.  
        6.2 Relationship to XML Digital Signatures
        The application of both encryption and digital signatures over portions of
          an XML document can make subsequent decryption and signature verification
          difficult. In particular, when verifying a signature one must know whether
          the signature was computed over the encrypted or unencrypted form of
          elements.




    

        A separate, but important, issue is introducing cryptographic
          vulnerabilities when combining digital signatures and encryption over a
          common XML element. Hal Finney has suggested that encrypting digitally signed
          data, while leaving the digital signature in the clear, may allow plaintext
          guessing attacks. This vulnerability can be mitigated by using secure hashes
          and the nonces in the text being processed.
        In accordance with the requirements document [XML-ENCRYPTION-REQ] 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 digest or signature over that data should
              be encrypted. This satisfies the first issue in that only those
              signatures that can be seen can be validated. It also addresses the
              possibility of a plaintext guessing vulnerability, though it may not be
              possible to identify (or even know of) all the signatures over a given
              piece of data.
          Employ the "decrypt-except" signature transform [XMLENC-DECRYPT]. It works as follows:
              during signature transform processing, if you encounter a decrypt
              transform, decrypt all encrypted content in the document except for those
              excepted by an enumerated set of references.
        Additionally, while the following warnings pertain to incorrect inferences
          by the user about the authenticity of information encrypted, applications
          should discourage user misapprehension by communicating clearly which
          information has integrity, or is authenticated, confidential, or
          non-repudiable when multiple processes (e.g., signature and encryption) and
          algorithms (e.g., symmetric and asymmetric) are used:
          When an encrypted envelope contains a signature, the
              signature does not 
              necessarily protect the authenticity or integrity of the
              ciphertext [Davis]. 
          While the signature secures plaintext it only covers that which is
              signed, recipients of encrypted messages must not infer integrity or
              authenticity of other unsigned information (e.g., headers) within the
              encrypted envelope, see [XMLDSIG-CORE1], section 8.1.1 Only What is
                Signed is Secure].
        6.3 Information Revealed
        Where a symmetric key is shared amongst multiple recipients, that
          symmetric key should only be used for the data intended for
          all recipients; even if one recipient is not directed to information
          intended (exclusively) for another in the same symmetric key, the information
          might be discovered and decrypted.
        Additionally, application designers should be careful not to reveal any
          information in parameters or algorithm identifiers (e.g., information in a
          URI) that weakens the encryption.
        6.4 Nonce and IV (Initialization Value or Vector)
        An undesirable characteristic of many encryption algorithms and/or their
          modes is that the same plaintext when encrypted with the same key has the
          same resulting ciphertext. While this is unsurprising, it invites various
          attacks which are mitigated by including an arbitrary and non-repeating
          (under a given key) data with the plaintext prior to encryption. In
          encryption chaining modes this data is the first to be encrypted and is
          consequently called the IV (initialization value or vector).
        Different algorithms and modes have further requirements on the
          characteristic of this information (e.g., randomness and secrecy) that affect
          the features (e.g., confidentiality and integrity) and their resistance to
          attack.
        Given that XML data is redundant (e.g., Unicode encodings and repeated
          tags ) and that attackers may know the data's structure (e.g., DTDs and
          schemas) encryption algorithms must be carefully implemented and used in this
          regard.
        For the Cipher Block Chaining (CBC) mode used by this specification, the
          IV must not be reused for any key and should be random, but it need not be
          secret. Additionally, under this mode an adversary modifying the IV can make
          a known change in the plain text after decryption. This attack can be avoided
          by securing the integrity of the plain text data, for example by signing
        
Note: CBC block encryption algorithms should not be used
          without consideration of possibly severe security risks. 
          For the Galois/Counter Mode (GCM) used by this specification, the IV
          must not be reused for any key and should be random, but it need
          not be secret. 
        
This specification permits recursive processing. For example, the
          following scenario is possible: EncryptedKey A
          requires EncryptedKey B to be decrypted, which
          itself requires EncryptedKey A! Or, an attacker
          might submit an EncryptedData for decryption that references
          network resources that are very large or continually redirected.
          Consequently, implementations should be able to restrict arbitrary recursion
          and the total amount of processing and networking resources a request can
          consume.
        6.6 Unsafe Content
        XML Encryption can be used to obscure, via encryption, content
          that applications (e.g., firewalls, virus detectors, etc.) consider unsafe
          (e.g., executable code, viruses, etc.). Consequently, such applications must
          consider encrypted content to be as unsafe as the unsafest content
          transported in its application context. Consequently, such applications may
          choose to (1) disallow such content, (2) require access to the decrypted form
          for inspection, or (3) ensure that arbitrary content can be safely processed
          by receiving applications.
        6.7 Error Messages 
          Implementations SHOULD NOT provide detailed error responses related to
          security algorithm processing. Error messages should be limited to a
          generic error message to avoid providing information to a potential
          attacker related to the specifics of the algorithm implementation. For
          example, if an error occurs in  decryption processing the error
          response should be a generic message providing no
          specifics on the details of the processing error.
        6.8 Timing Attacks 
          It has been known for some time that it is feasible for an attacker to
          recover keys or cleartext by repeatedly sending chosen ciphertext and
          measuring the time required to process different requests with
          different types of errors. It has been demonstrated that attacks of
          this type are practical even when communicating over large and busy
          networks, especially if the receiver is willing to process large
          numbers of ciphertext blocks.
          Implementers SHOULD ensure that distinct errors detected during
          security algorithm processing do not consume systematically different
          amounts of processing time from each other. Implementers SHOULD
          consult the technical literature for more details on specific attacks
          and recommended countermeasures. 
          Deployments SHOULD treat as suspect inputs when a large number of security
          algorithm processing errors are detected within a short period of
          time, especially in messages from the same origin.
        6.9 CBC Block Encryption Vulnerability 
          Note: CBC block encryption algorithms
          should not be used without 
          consideration of possibly severe
            security risks. 
      An implementation is conformant to this specification if it successfully
        generates syntax according to the schema definitions and satisfies all
        MUST/REQUIRED/SHALL requirements, including algorithm support and processing. Processing requirements are specified
        over the roles of decryptor, encryptor, and their calling application.
      8. XML Encryption Media Type
        8.1 Introduction
        XML Encryption Syntax and Processing (XMLENC-CORE1, 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.
        The application/xenc+xml media type allows XML Encryption
          applications to identify encrypted documents. Additionally it allows
          applications cognizant of this media-type (even if they are not XML
          Encryption implementations) to note that the media type of the decrypted
          (original) object might be a type other than XML.
        8.2 application/xenc+xml Registration
        This is a media type registration as defined in Multipurpose Internet Mail
          Extensions (MIME) Part Four: Registration Procedures [MIME-REG]




    

        Type name: application
        Subtype name: xenc+xml
        Required parameters: none
        Optional parameters: charset
          The allowable and recommended values for, and interpretation of the
            charset parameter are identical to those given for 'application/xml' in
            section 3.2 of RFC 3023 [XML-MT].
        Encoding considerations:
          The encoding considerations are identical to those given for
            'application/xml' in section 3.2 of RFC 3023 [XML-MT].
        Security considerations:
          See the (XMLENC-CORE1, this document) Security Considerations section.
        Interoperability considerations: none
        Published specification:  (XMLENC-CORE1, this document)
        Applications which use this media type:
          XML Encryption is device-, platform-, and vendor-neutral and is supported
          by a range of Web applications.
        Additional Information:
          Magic number(s): none
            Although no byte sequences can be counted on to consistently identify XML
            Encryption documents, there will be XML documents in which the root
            element's QName's LocalPart is
            'EncryptedData' or 'EncryptedKey' with an
            associated namespace name of 'http://www.w3.org/2001/04/xmlenc#'.
            The application/xenc+xml type name MUST only be used for
            data objects in which the root element is from the XML Encryption
            namespace. XML documents which contain these element types in places
            other than the root element can be described using facilities such as [XMLSCHEMA-1], [XMLSCHEMA-2].
          File extension(s): .xml
          Macintosh File Type Code(s): "TEXT"
        Person & email address to contact for further information:
          World Wide Web Consortium <web-human at w3.org>
        Intended usage: COMMON
        Author/Change controller:
        The XML Encryption specification is a work product of the World Wide Web
          Consortium (W3C) which has change control over the specification.
      9. Schema
        9.1 XSD Schema
          
XML Encryption Core Schema Instance
          xenc-schema.xsd
          XML Encryption 1.1 Schema Instance
          xenc-schema11.xsd
          This schema document defines the additional material defined in
            XML Encryption 1.1. 
          Example (non-normative)
          enc-example.xml (not cryptographically
            valid but exercises much of the schema)
        9.2 RNG Schema
This section is non-normative.
        Non-normative RELAX NG schema [RELAXNG-SCHEMA] information is
          available in a separate document [XMLSEC-RELAXNG].
      
A. Reserved Algorithm Identifiers
      This informative section outlines the definition and
        reserves identifiers for algorithms
        that have no requirements for implementation 
        and  have not been tested for interoperability. 
        A.1 AES KeyWrap with Padding
This section is non-normative.
          Identifiers:
          http://www.w3.org/2009/xmlenc11#kw-aes-128-pad
          
http://www.w3.org/2009/xmlenc11#kw-aes-192-pad
          
http://www.w3.org/2009/xmlenc11#kw-aes-256-pad
          These identifiers are reserved for symmetric key wrapping
          using the AES key wrap with padding 
          algorithm with a 128, 192, and 256 bit AES key encrypting
          key, respectively.  Implementation of 
          AES key wrap with padding is defined in [AES-WRAP-PAD].
          The algorithm is defined for inputs 
          between 9 and 2^32 octets.  Unlike the unpadded AES Key
          Wrap algorithm, the input length is not 
          constrained to multiples of 64 bits (8 octets).
          Note that the wrapped key will be distinct from the one
          generated by the unpadded AES Key Wrap 
          algorithm, even if the input length is a multiple of 64 bits.
B. References
Dated references below are to the latest known or appropriate edition of the referenced work.  The referenced works may be subject to revision, and conformant implementations may follow, and are encouraged to investigate the appropriateness of following, some or all more recent editions or replacements of the works cited. It is in each case implementation-defined which  editions are supported.
B.1 Normative references
[AES]
NIST FIPS 197: Advanced Encryption Standard (AES). November 2001. URL: http://csrc.nist.gov/publications/fips/fips197/fips-197.pdf
[AES-WRAP]
J. Schaad; R. Housley. RFC3394: Advanced Encryption Standard (AES) Key Wrap Algorithm. September 2002. IETF Informational RFC. URL: http://www.ietf.org/rfc/rfc3394.txt
[AES-WRAP-PAD]
R. Housley; M. Dworkin. RFC 5649: Advanced Encryption Standard (AES) Key Wrap with Padding Algorithm. August 2009.    IETF Informational RFC. URL: http://www.ietf.org/rfc/rfc5649.txt
[ANSI-X9-44-2007]
ANSI X9.44-2007: Key Establishment Using Integer Factorization Cryptography. URL: http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI+X9.44-2007
[CMS-WRAP]
R. Housley. RFC3217: Triple-DES and R2 Key Wrapping. December 2001. IETF Informational RFC. URL: http://www.ietf.org/rfc/rfc3217.txt
[DES]
NIST FIPS 46-3: Data Encryption Standard (DES) . October 1999. URL: http://csrc.nist.gov/publications/fips/fips46-3/fips46-3.pdf
[ESDH]
E. Rescorla.  Diffie-Hellman Key Agreement Method.. IETF RFC 2631 Standards Track, 1999. URL: http://www.ietf.org/rfc/rfc2631.txt
[EXI]
Takuki Kamiya; John Schneider. Efficient XML Interchange (EXI) Format 1.0. 8 December 2009. W3C Candidate Recommendation. URL: http://www.w3.org/TR/2009/CR-exi-20091208/
[FIPS-180-3]
FIPS PUB 180-3 Secure Hash Standard.  U.S. Department of Commerce/National Institute of Standards and Technology. URL: http://csrc.nist.gov/publications/fips/fips180-3/fips180-3_final.pdf
[FIPS-186-3]
FIPS PUB 186-3:  Digital Signature Standard (DSS). June 2009. U.S. Department of Commerce/National Institute of Standards and Technology. URL: http://csrc.nist.gov/publications/fips/fips186-3/fips_186-3.pdf
[HMAC]
H. Krawczyk, M. Bellare, R. Canetti. HMAC: Keyed-Hashing for Message Authentication. February 1997. IETF RFC 2104.  URL: http://www.ietf.org/rfc/rfc2104.txt
[NFC]
M. Davis, Ken Whistler. TR15, Unicode Normalization Forms.. 17 September 2010, URL: http://www.unicode.org/reports/tr15/
[PKCS1]
J. Jonsson and B. Kaliski. Public-Key Cryptography Standards (PKCS) #1: RSA Cryptography Specifications  Version 2.1. RFC 3447 (Informational), February  2003. URL: http://www.ietf.org/rfc/rfc3447.txt 
[PKCS5]
B. Kaliski. PKCS #5 v2.0: Password-Based Cryptography Standard. September 2000. IETF RFC 2898. URL: http://www.ietf.org/rfc/rfc2898.txt
[PKCS5Amd1]
PKCS #5 v2.0 Amendment 1: XML Schema for Password-Based Cryptography RSA Laboratories, March 2007. URL: ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5v2/pkcs-5v2-0a1.pdf
[RANDOM]
D.  Eastlake, S. Crocker, J. Schiller. Randomness Recommendations for Security.. IETF RFC 4086. June 2005. URL: http://www.ietf.org/rfc/rfc4086.txt
[RFC2045]
N. Freed and N. Borenstein. Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies. November 1996. URL: http://www.ietf.org/rfc/rfc2045.txt 
[RFC2119]
S. Bradner. Key words for use in RFCs to Indicate Requirement Levels. March 1997. Internet RFC 2119.  URL: http://www.ietf.org/rfc/rfc2119.txt 
[RFC4055]
J. Schaad, B. Kaliski, R. Housley. Additional Algorithms and Identifiers for RSA Cryptography for use in the Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile. June 2005. IETF RFC 4055. URL: http://www.ietf.org/rfc/rfc4055.txt
[RIPEMD-160]
B. Preneel, A. Bosselaers, and H. Dobbertin. The Cryptographic Hash Function RIPEMD-160. CryptoBytes, Volume 3, Number 2. pp. 9-14, RSA Laboratories 1997. URL: http://www.cosic.esat.kuleuven.be/publications/article-317.pdf
[SP800-38D]
M. Dworkin.  NIST Special Publication 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC. November 2007 URL: http://csrc.nist.gov/publications/nistpubs/800-38D/SP-800-38D.pdf
[SP800-56A]
 NIST Special Publication 800-56A: Recommendation for Pair-Wise Key Establishment Schemes Using Discrete Logarithm Cryptography (Revised). March 2007 URL: http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf
[SP800-67]
 Recommendation for the Triple Data Encryption Algorithm (TDEA) Block Cipher, Revised January 2012. SP-800-67 Revision 1. U.S. Department of Commerce/National Institute of Standards and Technology. URL: http://csrc.nist.gov/publications/nistpubs/800-67-Rev1/SP-800-67-Rev1.pdf
[URI]
T. Berners-Lee; R. Fielding; L. Masinter. Uniform Resource Identifiers (URI): generic syntax. January 2005. RFC 3986. URL: http://www.ietf.org/rfc/rfc3986.txt
[XML-ENCRYPTION-REQ]
Joseph Reagle. XML Encryption Requirements. 4 March 2002. W3C Note. URL: http://www.w3.org/TR/2002/NOTE-xml-encryption-req-20020304
[XML-NAMES]
Richard Tobin et al. Namespaces in XML 1.0 (Third Edition). 8 December 2009. W3C Recommendation. URL: http://www.w3.org/TR/2009/REC-xml-names-20091208/
[XML10]
C. M. Sperberg-McQueen et al. Extensible Markup Language (XML) 1.0 (Fifth Edition). 26 November 2008. W3C Recommendation. URL: http://www.w3.org/TR/2008/REC-xml-20081126/
[XMLDSIG-CORE1]
D. Eastlake; J. Reagle; D. Solo; F. Hirsch; T. Roessler; K. Yiu. XML Signature Syntax and Processing Version 1.1. 11 April 2013. W3C Recommendation. URL: http://www.w3.org/TR/2013/REC-xmldsig-core1-20130411/
[XMLSCHEMA-1]
Henry S. Thompson et al. XML Schema Part 1: Structures Second Edition. 28 October 2004. W3C Recommendation. URL: http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/
[XMLSCHEMA-2]
Paul V. Biron; Ashok Malhotra. XML Schema Part 2: Datatypes Second Edition. 28 October 2004. W3C Recommendation. URL: http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/
[XPATH]
James Clark; Steven DeRose. XML Path Language (XPath) Version 1.0. 16 November 1999. W3C Recommendation. URL: http://www.w3.org/TR/1999/REC-xpath-19991116/
B.2 Informative references
[Davis]
Defective Sign & Encrypt in S/MIME, PKCS#7, MOSS, PEM, PGP, and XML. D. Davis. USENIX Annual Technical Conference. 2001. URL: http://www.usenix.org/publications/library/proceedings/usenix01/davis.html
[ECC-ALGS]
D. McGrew; K. Igoe; M. Salter. RFC 6090: Fundamental Elliptic Curve Cryptography Algorithms. February 2011. IETF Informational RFC. URL: http://www.rfc-editor.org/rfc/rfc6090.txt
[MIME-REG]
N. Freed, J. Klensin. RFC 4289: Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures. December 2005. Best Current Practice. URL: http://www.ietf.org/rfc/rfc4289.txt
[OAEP-ATTACK]
Manger, James.  A Chosen Ciphertext Attack on RSA Optimal Asymmetric Encryption Padding (OAEP) as Standardized in PKCS #1 v2.0. URL: http://archiv.infsec.ethz.ch/education/fs08/secsem/Manger01.pdf
[RELAXNG-SCHEMA]
Information technology -- Document Schema Definition Language (DSDL) -- Part 2: Regular-grammar-based validation -- RELAX NG. ISO/IEC 19757-2:2008. URL: http://standards.iso.org/ittf/PubliclyAvailableStandards/c052348_ISO_IEC_19757-2_2008(E).zip
[RFC3218]
E. Rescorla. Preventing the Million Message Attack on Cryptographic Message Syntax (RFC 3218). January 2002. RFC. URL: http://www.rfc-editor.org/rfc/rfc3218.txt
[SHA-1-Analysis]
McDonald, C., Hawkes, P., and J. Pieprzyk. SHA-1 collisions now 2⁵² . EuroCrypt 2009 Rump session. URL: http://eurocrypt2009rump.cr.yp.to/837a0a8086fa6ca714249409ddfae43d.pdf
[SHA-1-Collisions]
X. Wang, Y.L. Yin, H. Yu. Finding Collisions in the Full SHA-1. In Shoup, V., editor, Advances in Cryptology - CRYPTO 2005, 25th Annual International Cryptology Conference, Santa Barbara, California, USA, August 14-18, 2005, Proceedings, volume 3621 of LNCS, pages 17–36. Springer, 2005. URL: http://people.csail.mit.edu/yiqun/SHA1AttackProceedingVersion.pdf (also published in http://www.springerlink.com/content/26vljj3xhc28ux5m/)
[Tobin]
R. Tobin. Infoset for external entities. 2000. URL: http://lists.w3.org/Archives/Member/w3c-xml-core-wg/2000OctDec/0054 [XML Core mailing list, W3C Member Only].
[XML-C14N]
John Boyer. Canonical XML Version 1.0. 15 March 2001. W3C Recommendation. URL: http://www.w3.org/TR/2001/REC-xml-c14n-20010315
[XML-C14N11]
John Boyer; Glenn Marcy. Canonical XML Version 1.1. 2 May 2008. W3C Recommendation. URL: http://www.w3.org/TR/2008/REC-xml-c14n11-20080502/
[XML-EXC-C14N]
Donald E. Eastlake 3rd; Joseph Reagle; John Boyer. Exclusive XML Canonicalization Version 1.0. 18 July 2002. W3C Recommendation. URL: http://www.w3.org/TR/2002/REC-xml-exc-c14n-20020718/
[XML-INFOSET]
John Cowan; Richard Tobin. XML Information Set (Second Edition). 4 February 2004. W3C Recommendation. URL: http://www.w3.org/TR/2004/REC-xml-infoset-20040204/
[XML-MT]
M. Murata, S. St.Laurent, D. Kohn. XML Media Types. IETF RFC 3023. URL:  http://www.ietf.org/rfc/rfc3023.txt.
[XMLBASE]
Jonathan Marsh; Richard Tobin. XML Base (Second Edition). 28 January 2009. W3C Recommendation. URL: http://www.w3.org/TR/2009/REC-xmlbase-20090128/
[XMLENC-BACKWARDS-COMP]
Tibor Jager; Kenneth G. Paterson; Juraj Somorovsky. One Bad Apple: Backwards Compatibility Attacks on State-of-the-Art Cryptography. 2013. URL: http://www.nds.ruhr-uni-bochum.de/research/publications/backwards-compatibility/
[XMLENC-CBC-ATTACK]
Tibor Jager; Juraj Somorovsky. How to Break XML Encryption. 17-21 October 2011. CCS’11, ACM. URL: http://www.nds.ruhr-uni-bochum.de/research/publications/breaking-xml-encryption/
[XMLENC-CBC-ATTACK-COUNTERMEASURES]
Juraj Somorovsky; Jörg Schwenk. Technical Analysis of Countermeasures against Attack on XML Encryption - or - Just Another Motivation for Authenticated Encryption. 2011. URL: http://www.w3.org/2008/xmlsec/papers/xmlEncCountermeasuresW3C.pdf

Abstract

Status of This Document

Table of Contents

1. Introduction

1.1 Editorial and Conformance Conventions

1.2 Design Philosophy

1.3 Versions, Namespaces, URIs, and Identifiers

1.4 Acknowledgements

2. Encryption Overview and Examples

2.1 Encryption Granularity

2.1.1 Encrypting an XML Element

2.1.2 Encrypting XML Element Content (Elements)

2.1.3 Encrypting XML Element Content (Character Data)

2.1.4 Encrypting Arbitrary Data and XML Documents

2.1.5 Super-Encryption: Encrypting EncryptedData

2.2 EncryptedData and EncryptedKey Usage

2.2.1 EncryptedData with Symmetric Key ( KeyName )

2.2.2 EncryptedKey ( ReferenceList , ds:RetrievalMethod , CarriedKeyName )

3. Encryption Syntax

3.1 The EncryptedType Element

3.2 The EncryptionMethod Element

3.3 The CipherData Element

3.3.1 The CipherReference Element

3.5 Extensions to ds:KeyInfo Element

3.5.1 The EncryptedKey Element

3.5.2 The DerivedKey Element

3.5.3 The ds:RetrievalMethod Element

3.6 The ReferenceList Element

3.7 The EncryptionProperties Element

4.1 Intended Application Model

4.2 Well-known Type parameter values

4.3 Encryption

4.5.1 A Decrypt Implementation (Non-normative)

4.5.2 A Decrypt and Replace Implementation (Non-normative)

4.5.3.2 XML Attribute Considerations

4.5.4 Text Wrapping

5.1 Algorithm Identifiers and Implementation Requirements

5.1.1 Table of Algorithms

5.2 Block Encryption Algorithms

5.2.1 Padding

5.2.2 Triple DES

5.2.3 AES

5.2.4 AES-GCM

5.3 Stream Encryption Algorithms

5.4 Key Derivation

5.4.1 ConcatKDF

5.4.2 PBKDF2

5.5 Key Transport

5.5.1 RSA Version 1.5

5.5.2 RSA-OAEP

5.6 Key Agreement

5.6.1 Diffie-Hellman Key Values

5.6.2 Diffie-Hellman Key Agreement

5.6.2.1 Diffie-Hellman Key Agreement with Explicit Key Derivation Functions

5.6.2.2 Diffie-Hellman Key Agreement with Legacy Key Derivation Function

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

5.7.1 CMS Triple DES Key Wrap

5.7.2 AES KeyWrap

5.8.1 SHA1

5.8.2 SHA256

5.8.3 SHA384

5.8.4 SHA512

5.8.5 RIPEMD-160

5.9 Canonicalization

5.9.1 Inclusive Canonicalization

5.9.2 Exclusive Canonicalization

6.1 Chosen-Ciphertext Attacks

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

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

6.1.3 Backwards Compatibility Attacks

6.2 Relationship to XML Digital Signatures

6.3 Information Revealed

6.4 Nonce and IV (Initialization Value or Vector)

6.6 Unsafe Content

6.7 Error Messages

6.8 Timing Attacks

6.9 CBC Block Encryption Vulnerability

8. XML Encryption Media Type

8.1 Introduction

8.2 application/xenc+xml Registration

2.2 `EncryptedData` and `EncryptedKey` Usage

2.2.1 `EncryptedData` with Symmetric Key ( `KeyName` )

2.2.2 `EncryptedKey` ( `ReferenceList` , `ds:RetrievalMethod` , `CarriedKeyName` )

3.1 The `EncryptedType` Element

3.2 The `EncryptionMethod` Element

3.3 The `CipherData` Element

3.3.1 The `CipherReference` Element

3.5 Extensions to `ds:KeyInfo` Element

3.5.1 The `EncryptedKey` Element

3.5.2 The `DerivedKey` Element

3.5.3 The `ds:RetrievalMethod` Element

3.6 The `ReferenceList` Element

3.7 The `EncryptionProperties` Element

4.2 Well-known `Type` parameter values

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