This document specifies how to encrypt data in an XML-conformant manner. It describes how to perform fine-grained, element-based encryption of fragments within an XML Document as well as encrypt arbitrary binary data and include it an XML document. The technical requirements upon which this specification is based are summarized in Section 2. Subsequent Sections describe the XML Encryption syntax, processing rules, and XML Encryption schema along with selected examples of using this technology.

General principals upon which this specification is based include:

· Encrypted data and encrypted keying information are fundamentally different and the design should reflect this dichotomy

· Representation of the encrypted data and related keying material must be both efficient and flexible

· Required information should be kept to an absolute minimum

· It should be possible to encode all information needed to deal with an item with the item itself

· Whenever possible, the syntax and processing rules for encrypted keys and encrypted data should be harmonized.

· The design should address broad, cross application, needs while avoiding complexity required for addressing specific application domains. But, extensibility mechanisms should be available to meet these needs.

· It is desirable to provide consistency and compatibility with the existing XML Digital Signature draft standard [DSIG].

Non-goals within this specification include:

· Ability to encrypt arbitrary sub-portions of an XML document

· Ability to selectively encrypt portions of a text value associated with an XML Element

· Ability to encrypt only Attribute values associated with an XML Element

· Insuring an encrypted document is valid against a DTD, or XML Schema, against which the unencrypted document was valid

· Applying transformations such as compression to the data prior to encryption

While not radically different in intent than earlier proposals ([PROP1], [PROP2], and [NOTE] for example), the authors feel this proposal has advantages in terms of:

· A cleaner syntax that avoids the potential difficulties associated with deeply nested structures and context dependent element interpretation

· Clear differentiation between encrypted keys and encrypted data

· A flexible approach to incorporation of cipher text via reference

· Elimination of potentially dangerous attribute encryption support

2 Requirements

This section summarizes the key technical requirements for XML Encryption.

2.1 XML Conformance

This specification describes how to encrypt XML documents, XML document fragments, or arbitrary binary data (an octet sequence) and encode the encrypted data and related information as XML.

When operating on an XML document (or fragment), the result of applying XML Encryption is a transform operation on the XML document. If the unencrypted XML is valid with respect to an XML Schema “S”, it is not a requirement that the transformed document resulting from application of XML Encryption be valid with respect to “S”. It will always be possible, however, to construct a new schema “S1” which corresponds to the encrypted XML.

2.2 Namespaces

All XML Schemas defined in this specification reside in the XML Encryption namespace.

In this draft, the namespace “http://www.w3.org/2000/11/temp-xmlenc” will be used pending W3C allocation of a namespace for this effort.

2.3 Encrypted Data

Encrypted Data is a first class object and must be represented as a distinguished XML document fragment (schema defined in section 7). This is required to clearly identify where information is encoded as cipher text. This document fragment will always contain either the cipher text as a base64 encoded octet sequence or a URI reference and transformation instructions necessary to obtain the cipher text as an octet sequence. The latter mechanism is provided for flexibility and to support scenarios such as the encryption of a binary content stream where it would be inefficient to include the stream content directly in an XML document.

The Encrypted Data object may optionally contain information about how the cipher text may be decrypted. This can include the following:

· Reference to the key used to encrypt the data (see 2.4).

· Information on the encryption method used. This will typically be either a block or stream cipher, though one could use a public key algorithm, such as RSA, to encrypt a short octet sequence.

To simplify encoding and processing, only a single cipher text may be included within an Encrypted Data object. Also, it is implicit that all included information about the encryption key used will refer to the same key value.

To meet the needs of key applications, this specification supports encryption of:

· An XML Element, including the element tags

· An XML NodeList representing the contents of given XML Element

· An octet sequence that is not part of an XML Document

The type of data encrypted may be encoded as an attribute of the Encrypted Data to aid the decryptor in processing it. If the data is an XML Element, it is implicit the decrypted Element replaces the Encrypted Data object in a given XML Document context. Similarly, a decrypted NodeList replaces the Encrypted Data object in a given XML Document. An external octet sequence is always treated as external data relative to any XML Document, i.e., there is no implied document transform to be applied when the data is decrypted.

It has been suggested that encryption of individual XML Attribute nodes be supported. This is not allowed due to concerns over cryptographic vulnerabilities associated with encrypting enumerated Attributes (i.e., short octet sequences constrained to a limited number of known values) as well as syntactic challenges in clearly indicating when an Element contains encrypted Attributes.

Each Encrypted Data object is assumed to be independent and there is no requirement for indicating linkage or ordering between Encrypted Data objects. We do recognize that an encryptor may choose an approach in which decryption order and/or state propagation between Encrypted Data objects is important. For example, one may use the output from one decryption as the IV input to a second decryption. Or, if one has two Encrypted Data objects which reference doubly encrypted cipher text, then the decryption order is critical. In such cases, the encryptor may specify this information as part of the encryption method information.

Data transformations other than encryption are outside the scope of this specification as the requirements are application dependent. Such transforms could include XML canonicalization or data compression.

2.4 Encryption Key Sharing

In most situations, it is desirable to provide the recipient of an XML Encrypted Data object with information about the key used to encrypt the data. It is not however, mandatory and the key value may be implied if the encryptor/decryptor have established this key through some other means.

This specification is limited to specifying how to convey key information between entities in an XML compatible manner. Mechanisms for establishing trust relationships, negotiating pre-arranged secrets, and so forth are beyond the scope of this specification.

When specified, key sharing information is a first class object and encoded in a way that makes this obvious. For flexibility, we support specifying:

· A key value encrypted to the recipient

· Key attributes sufficient to allow the recipient to retrieve a key value stored elsewhere

Depending upon the application, one may include one or more types of information within an Encrypted Data object. Typically, only one type of information will be necessary. All included key sharing information must refer to a single encryption key value. It is recommended that key sharing information within an Encrypted Data object be targeted to a single recipient (or possibly a group sharing a common secret).

Note: It is possible, at some cost in complexity, to provide key sharing information for multiple recipients based on the proposed syntax in Section 8. Unless a compelling application for this can be identified, the authors recommend this not be supported.

Specification of key attributes is based on the existing KeyInfo Element defined in the XML Digital Signature specification. If one is using an asymmetric encryption algorithm, then the Digital Signature defined KeyInfo is adequate. If using a symmetric key, then we support indirect key references based on a key name and/or key references. To facilitate use of key names, there must be a simple way to indicate the name associated with an Encrypted Key value. For key references, we define a means to express a URI where the key is located. This is done using a new element in the context of a KeyInfo element. This avoids any potential confusion that might arise from reuse of the Digital Signature RetrivealMethod element. Direct inclusion of a clear text symmetric key value is not relevant in this context and is not supported.

2.4.1 Encrypted Key

When specifying an encrypted symmetric key value, a distinguished Encrypted Key object is used. This is distinct from, and uses a different encoding from Encrypted Data, to avoid context dependent processing. The Encrypted Key object always includes the encrypted symmetric key cipher text as a base64 encoded octet sequence. In addition, the Encrypted Key object may include:

· Information on the encryption method used, either a public key, block, or stream cipher

· Information about the encryption key encoded using the KeyInfo Element. As noted previously, this is based on the XML Digital Signature draft standard. In this context, it may include an asymmetric public key value used to encrypt the symmetric key or a reference to the encryption key.

· A list of references to Encrypted Data objects whose cipher text is encrypted with this symmetric key

· A list of references to other Encrypted Key objects whose cipher text is encrypted with this symmetric key

The latter capability is included primarily to support key update based on existing shared symmetric keys.

2.5 Encrypted Data and Key Sharing Object Composition

The preceding sections identified some of the rules for combining encrypted data and key sharing information. This section provides a fuller treatment of this issue.

A given XML Document may contain any number of Encrypted Data objects. The Encrypted Data objects are independent and it is not valid to nest these objects, i.e., an Encrypted Data may not be a child of an Encrypted Data. Each Encrypted Data object may include optional information about the key used to encrypt the cipher text. This can be either in the form of a KeyInfo element referencing a known key an Encrypted Key object or both.

Hence, the following are examples of valid relationships between Encrypted Data objects in an XML Document:

+---------------------------+

|XML Document A |

| +----------------+ |

| | Encrypted | |

| | Data-A | |

| +----------------+ |

| |

| +----------------+ |

| | Encrypted | |

| | Data-B | |

| | +------------+| |

| | |KeyInfo || |

| | +------------+| |

| +----------------+ |

| |

| +----------------+ |

| |Encrypted | |

| | Data-C | |

| | +------------+| |

| | |Encrypted || |

| | | Key-1 || |

| | +------------+| |

| +----------------+ |

+---------------------------+

While the relationship depicted below is invalid:

+--------------------+

| Encrypted |

| Data-A |

| +------------+ |

| | Encrypted | |

| | Data-B | |

| +------------+ |

+--------------------+

An XML document may contain any number of Encrypted Key objects, either as children of an Encrypted Data object, or as independent objects. An Encrypted Key object may not be a child of another Encrypted Key object. The Encrypted Key object may include a KeyInfo Element with information to help the recipient decrypt the key cipher text.

Hence, the following are examples of valid relationships between Encrypted Key and Encrypted Data objects:

+----------------------+ +-------------------------+

|XML Document A | |XML Document B |

| +------------+ | | +------------------+ |

| | Encrypted | | | | Encrypted | |

| | Key-1 | | | | Data-B | |

| +------------+ | | | +-----------+ | |

| | | | |KeyInfo | | |

| +------------+ | URI | | | Encrypted| | |

| | Encrypted |<------------- | Key Ref. | | |

| | Key-2 | | Ref.| | + ----------+ | |

| +------------+ | | +------------------+ |

| | | |

| +----------------+ | | |

| |Encrypted | | | |

| | Data-A | | | |

| | +------------+| | | |

| | |Encrypted || | | |

| | | Key-3 || | | |

| | +------------+| | | |

| +----------------+ | | |

+----------------------+ +-------------------------+

While the relationship depicted below is invalid:

+--------------------+

| Encrypted |

| Key-1 |

| +------------+ |

| | Encrypted | |

| | Key-2 | |

| +------------+ |

+--------------------+

An Encrypted Key object may include references to Encrypted Data object or other Encrypted Key objects. In both cases, the reference indicates that the referenced object cipher text is encrypted using the key value contained with the referencing Encrypted Key object. As depicted below, references in the Encrypted Key-1 object indicate that the Encrypted Data-A cipher text and Encrypted Key-2 cipher text are encrypted using the symmetric key value in Encrypted Key-1.

+------------+ +-----------+

| Encrypted |---------------------->| Encrypted |

| Key-1 |-- URI References | Data-A |

+------------+ \--- +-----------+

\

\ +-----------+

------>| Encrypted |

| Key-2 |

+-----------+

2.6 Relationship to XML Digital Signatures

It is recognized that application of both encryption and digital signatures over an XML document may interact in ways that make subsequent decryption and signature verification difficult. In particular, in verifying a signature one must be aware of whether the signature was computed over the encrypted or unencrypted representation of elements contained in the document/fragment. This may be unclear if there are multiple signatures and encryptions applied over a set of fragments as XML provides no syntax defining an implicit ordering.

The XML Digital Signature Working Group did not anticipate and address this problem. Hence, the XML Encryption Working Group must create the mechanisms allowing encryption and signatures work effectively together. The basic requirement is to communicate to the recipient any dependency between a given Signature element and the encryption element(s) applied to a common XML document(s).

The preferred approach is definition of a method for marking an XML Digital Signature “Signature” element to indicate when the signature has been computed over cipher text. This would indicate the cipher text should not be decrypted prior to signature verification. Alternate approaches, such as marking encryptions applied after a signature, are viewed as unworkable since both signatures and encryptions may be applied over external data via references. Hence, when performing encryption it is impossible to determine all signatures that may exist over the data.

A separate, but important, issue is introducing cryptographic vulnerabilities when combining digital signatures and encryption over a common XML fragment. Hal Finney has suggested that encrypting digitally signed data, while leaving the digital signature in the clear, may allow plaintext guessing attacks. To address this vulnerability, one should encrypt the digital signature whenever the signed data is encrypted. As noted above however, that this may be impossible as the encryptor can not determine all digital signatures over a given fragment with any certainty. Hence, we recommend, but don’t mandate, encryption of the appropriate Signature element(s) when encrypting signed data.

2.7 Encryption Properties

It has been proposed (see [NOTE]) that XML Encryption explicitly support incorporation of encryption properties as a unique element within the Encrypted Data and/or Encrypted Key objects. Such data is application dependent and there appears to be no identifiable set of properties that have widespread utility.

In addition, we note that any such properties included within the Encrypted Data or Encrypted Key objects would be in the clear, unauthenticated, and subject to undetectable modification. For these reasons, this specification does not define how to include application specific encryption properties. There are suitable mechanisms defined in XML Digital Signature for including, and digitally signing, such information. This supports a strong binding between these attributes and the encrypted information and is the recommended approach.

3. Syntax Description

This section provides a detailed description of the syntax and features for XML encryption. Features described in this section are mandatory to implement unless otherwise noted. The syntax is described via [XML-Schema] fragments, the full syntax is in section 7.

3.1 The EncryptedData element

The EncryptedData element is the core element in the syntax. Not only does it contain the encrypted data value, but it also provides the element that can be used as a document root.

There are four different ways to define the location of the key material to be used in decrypting the included data. These are:

· The key value may be explicitly included within an EncryptedKey element

· The key value may be referenced using the KeyInfo element. This reference can either be indirect (via a key name) or direct (using the EncryptedKeyReference to point to the key value).

· An EncryptedKey element can refer to the EncryptedData element (a link from the key to the data).

· The key material is known to the recipient of the object either by context or based on external protocol elements.

</sequence>

</complexType>

</element>

Where:

xmlns:xenc='http://www.w3.org/2000/11/temp-xmlenc’

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

EncryptedKey is an optional element that contains the key used to encrypt the data in an encrypted form. If the EncryptedKey element is present, the KeyInfo element is normally absent.

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

KeyInfo is an optional element containing a method of identifying the key that was used in the encryption process and is defined in the XML Digital Signature draft standard. This document defines a new element “EncryptedKeyReference” to be placed in the KeyInfo element. If both KeyInfo and EncryptedKey are present in the structure, the key value referred to must contain the same value in both instances.

CipherText is a mandatory element that provides the encrypted data.

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

Type is an optional attribute identifying type information about the decrypted content. Valid values for this attribute are:

Element — indicating that the encrypted data represents an XML element; specifically, it is the XML element that, before encryption, existed where the <EncryptedData> element now exists.

NodeList — indicating that the encrypted data represents the content of an XML element (or an entire XML document); specifically, the decrypted result will be a DOM node list representing the content of the XML element which is the parent of the <EncryptedData> element being processed. For an entire document, the decrypted result will be a DOM node list including the prolog and root element.

media type — indicating that the encrypted data represents arbitrary data with the stated media type. For example if the encrypted data represents an HTML document, the value of the Type attribute would be "text/html", of if the encrypted data was a GIF file, the value of the Type attribute would be "image/gif".

3.2 The EncryptedKeyReference element

The EncryptedKeyReference element provides a way to express a link from an element describing encrypted data to the EncryptedKey element containing the key used to decrypt it. This element is placed within a Digital Signature “KeyInfo” element. The element may occur multiple times within a KeyInfo element referring to different EncryptedKey objects containing the same key value but encrypted in different ways for different recipients.

</sequence>

</complexType>

</element>

Where:

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

EncryptedKeyReference uses the same syntax and dereferencing behavior as the RetrievalMethod element in the XML Digital Signature syntax, except the type attribute is absent since the EncryptedKey element is the only legal result of following the reference.

3.3 The EncryptedKey element

The EncryptedKey element is used to transport encryption keys from the originator to a known recipient(s).

</sequence>

</complexType>

</element>

Where:

xmlns:xenc='http://www.w3.org/2000/11/temp-xmlenc’

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

EncryptionMethod is an optional element containing the algorithm information used to encrypt the key. If the value is absent, the recipient is assumed to be able to infer the algorithm from either context or other protocol information.

ReferenceList is an optional element containing pointers to data elements that were encrypted using this key. The reference list can contain references to either EncryptedKey or EncryptedData elements as the key could be used to encrypted data in either object. (If references are desired from the encrypted data to the EncryptedKey element, the EncryptedKeyReference element should be placed in the appropriate KeyInfo elements [JLS1] ).

KeyInfo is an optional element containing a method of identifying the key that was used in the encryption process. If the element is absent, the recipient is assumed to be able to infer the key value either from context or other protocol information.

CipherText is a mandatory element that provides contains the encrypted data.

Id is an optional attribute providing for the standard XML method of tagging an element with a string id.

NameKey is an optional attribute providing for a method of identifying the embedded key value by name. The same NameKey label, unlike an id label, may occur multiple times within a single document. The value of the key is to be the same in all EncryptedKey elements identified with the same NameKey label. The KeyName element in the KeyInfo object is used to refer to a NameKey labeled structure.

3.4 The EncryptionMethod element

EncryptionMethod is an element that specifies the algorithm used for encryption. The algorithm identifies all of the cryptographic functions involved in the operation. The algorithm identifies all parameters used in the cryptographic operation.

</sequence>

</complexType>

</element>

Algorithm is a mandatory attribute holding a URI identifying the algorithm. The algorithm determines the contents of the node-list within the EncryptionMethod element.

3.5 The ReferenceList element

ReferenceList is an element that contains pointers from keys to data encrypted by the keys. Links in the opposite direction are provided by the EncryptedDataReference elements placed in the KeyInfo element.

</sequence>

</complexType>

</element>

</sequence>

</complexType>

</element>

</sequence>

</complexType>

</element>

Where:

xmlns:xenc='http://www.w3.org/2000/11/temp-xmlenc’

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

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

3.6 The CipherText element

The CipherText element contains either the actual encrypted data/key or a reference to the location of the encrypted data. The schema for the two forms is indicated below. Only the non-reference version is to be used inside of an EncryptedKey structure. In the simple type form (CipherText1) the CDATA of the element contains the base64 encoded cipher text. If the URI attribute is present then the cipher text may not be contained in the CDATA of the element.

</choice>

</complexType>

</element>

Where:

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

Transforms is an optional element that provides a list of transform operations to be applied to the data stream retrieved from the URI attribute in order to obtain the cipher text octet stream. If the URI attribute is present and transforms is absent, there are no implicit transform operations done. In other words, if the target of the URI is a base64 encoded text stream, the base64 removal transformation must be explicitly given.

3.7 The EncryptedReference element

The EncryptedReference element provides a way to indicate that data, over which an XML Digital Signature (xmlns:ds) has been computed, was encrypted. In essence, it indicates the data should not be decrypted prior to signature verification. This element may only appear within a ds:Reference element within a ds:Signature element. A separate EncryptedReference element should be included for each EncryptedData and EncryptedKey element within the data to be signed.

This presumes one will not compute a digital signature over a portion of an EncryptedData or EncryptedKey element. Signatures computed in this way are not compliant with this specification and persons doing this should not use the EncryptedReference element.

</complexType>

</element>

The URI attribute should only reference an EncryptedData or EncryptedKey element. References to other elements are invalid and the EncryptedReference may be ignored when verifying the signature.

4. Processing Rules

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

4.1 Encryption

For each data item or key to be encrypted:

1. Select the algorithm (and parameters) to be used in encrypting this item.

2. Generate or obtain the encryption key to be used.

3. Locate the octet sequence to be encrypted.

3.1 If the data to be encrypted is an element, the octet sequence is the UTF-8 encoded string representation of the element. This string begins with the left angle bracket of the start tag of the element, and ends with the right angle bracket of the end tag of the element, both inclusive. This string is interpreted as an octet sequence and encrypted by the key obtained in the previous step.

3.2 If the data to be encrypted is an element content (i.e., a NodeList), the octet sequence is the UTF-8 encoded string representation of the NodeList. The string starts with the first character following the right angle bracket of the start tag of the element, and ends with the last character before the left angle bracket of the end tag of the element, both inclusive. The string is interpreted as an octet sequence and encrypted by the key obtained in the previous step.

3.3 If the data to be encrypted is an external octet sequence, it is encrypted by the key obtained in the previous step.

4. Build the XML structure for this encryption step

4.1 If the data being encrypted is an element or node list, the unencrypted data is removed and replaced with the new XML structure.

4.2 If the data being encrypted is an external octet sequence, replace the value with the encrypted result and create an EncryptedData structure referencing the encrypted data. The EncryptedData structure can be inserted into another XML Document or used as the top-level node in a new XML Document.

4.2 Decryption

For each item to be decrypted:

1. Parse the XML to determine the algorithm, parameters and key to be used.

2. Locate the data to be decrypted

3. If necessary, decrypt the data encryption key. Alternatively, retrieve from some local store using the provided attributes or implicit binding.

4. Perform the data decryption operation.

5. If it is an EncryptedData structure and the type is “Element” or “NodeList”, then transform the plain text document. This means the decrypted octet sequence should be interpreted as a UTF-8 encoded string representing a serialized XML fragment, which might not be well-formed XML. This XML fragment is converted into the character encoding of the surrounding document and then replaces the data in the document starting with the left angle bracket of the start tag of the EncryptedData element and ending with the right angle bracket of the end tag of the element. If the data type is an external media type, then the data is made available to the using application, but no document transform is done. How the decrypted data is made available is an implementation decision and is beyond the scope of this specification.

5 Examples

5.1 Encrypted Content by Named Key

In this example, the cipher text is encrypted using a symmetric key with the name “NamedKey”.

<xenc:EncryptedData xmlns:xenc='http://www.w3.org/2000/11/temp-xmlenc’>

<xenc:EncryptionMethod xenc:Algorithm=”urn:nist-gov:tripledes-ede-cbc”>

<s0:IV xmlns:s0=’http://somens’>ABCD</s0:IV>

</xenc:EncryptionMethod>

<ds:KeyInfo xmlns:ds=’http://www.w3.org/2000/09/xmldsig#’>

<ds:KeyName>NamedKey</ds:KeyName>

</ds:KeyInfo>

<xenc:CipherText>DEADBEEF</xenc:CipherText>

</xenc:EncryptedData>

5.2 Encrypted Content with Content Key encrypted for Recipient

In this example, the encrypted data cipher text is encrypted using a symmetric key known by the identifier “Content Key”. This key is encrypted to the recipient. The encrypted symmetric key has been encrypted using the RSA algorithm and a public key known as “John Doe Public Key”.

<xenc:EncryptedKey NameKey=”Content Key” xmlns:xenc='http://www.w3.org/2000/11/temp-xmlenc’>

<xenc:EncryptionMethod xenc:Algorithm=” urn:rsadsi-com:rsa-v2.0”/>

<ds:KeyInfo xmlns:ds=’http://www.w3.org/2000/09/xmldsig#’>

<ds:KeyName>John Doe Public Key</ds:KeyName>

</ds:KeyInfo>

<xenc:CipherText>ENCRYPTED KEY</xenc:CipherText>

</xenc:EncryptedKey>

<xenc:EncryptedData xmlns:xenc='http://www.w3.org/2000/11/temp-xmlenc’>

<xenc:EncrpytionMethod xenc:Algorithm=” urn:nist-gov:aes-128-cbc”>

<s0:IV xmlns:s0=’http://somens’>ABCD</s0:IV>

</xenc:EncryptionMethod>

<ds:KeyInfo xmlns:ds=’http://www.w3.org/2000/09/xmldsig#’>

<ds:KeyName>Content Key</ds:KeyName>

</ds:KeyInfo>

<xenc:CipherText>DEADBEEF</xenc:CipherText>

</xenc:EncryptedData>

5.3 Encrypted Content with Content Key encrypted for Recipient, using ReferenceList

This example is similar to that shown in 5.2, only in this case the encrypted key value is found by an explicit URI reference.

<xenc:EncryptedKey Id=”EK” xmlns:xenc='http://www.w3.org/2000/11/temp-xmlenc’>

<xenc:EncryptionMethod xenc:Algorithm=” urn:rsadsi-com:rsa-v2.0”/>

<xenc:ReferenceList>

<xenc:DataReference URI=”#ED”/>

</xenc:ReferenceList>

<ds:KeyInfo xmlns:ds=’http://www.w3.org/2000/09/xmldsig#’>

<ds:KeyName>John Doe Public Key</ds:KeyName>

</ds:KeyInfo>

<xenc:CipherText>xyzabc</xenc:CipherText>

</xenc:EncryptedKey>

<xenc:EncryptedData Id=”ED” xmlns:xenc='http://www.w3.org/2000/11/temp-xmlenc’>

<xenc:EncryptionMethod xenc:Algorithm=” urn:nist-gov:aes-128-cbc”>

<s0:IV xmlns:s0=’http://somens’>ABCD</s0:IV>

</xenc:EncryptionMethod>

<ds:KeyInfo xmlns:ds=’http://www.w3.org/2000/09/xmldsig#’>

<xenc:EncryptedKeyReference URI=”#EK”/>

</ds:KeyInfo>

<xenc:CipherText>DEADBEEF</xenc:CipherText>

</xenc:EncryptedData>

5.4 Chaining between EncryptedData Elements

In this example, we show how chaining between two EncryptedData cipher texts. The EncryptedData “ED1” can be decrypted using the explicit IV and referenced symmetric key. EncryptedData “ED2” can be decrypted by using the output from decrypting ED1 as the input IV to “ED2”.

<xenc:EncryptedData Id=’ED1’ xmlns:xenc='http://www.w3.org/2000/11/temp-xmlenc’>

<xenc:EncryptionMethod xenc:Algorithm=”urn:nist-gov:tripledes-ede-cbc”>

<s0:IV xmlns:s0=’http://somens’>ABCD</s0:IV>

</xenc:EncryptionMethod>

<ds:KeyInfo xmlns:ds=’http://www.w3.org/2000/09/xmldsig#’>

<ds:KeyName>NamedKey</ds:KeyName>

</ds:KeyInfo>

<xenc:CipherText>DEADBEEF</xenc:CipherText>

</xenc:EncryptedData>

...

<xenc:EncryptedData Id=’ED2’ xmlns:xenc='http://www.w3.org/2000/11/temp-xmlenc’>

<xenc:EncryptionMethod xenc:Algorithm=”urn:nist-gov:tripledes-ede-cbc”>

<s0:IVRef xmlns:s0=’http://somens’ Ref=’#ED1’/>

</xenc:EncryptionMethod>

<ds:KeyInfo xmlns:ds=’http://www.w3.org/2000/09/xmldsig#’>

<ds:KeyName>NamedKey</ds:KeyName>

</ds:KeyInfo>

<xenc:CipherText>DEADBEEF</xenc:CipherText>

</xenc:EncryptedData>

5.5 Encrypting an XML element

When encrypting an XML element, replace the element to be encrypted with an <EncryptedData> element. The <CipherText> is the encrypted string formed by serializing the element starting from its start tag, including all its children, through to its end tag inclusively. For example, this plaintext XML

<root>

<foo>

<a/>

</ElementToBeEncrypted>

</element>

</root>

becomes (assuming the encryption method and and key sharing information is implicitly known).

<root>

<foo>

<xenc:EncryptedData xmlns:xenc='http://www.w3.org/2000/11/temp-xmlenc’ Type=”Element”>

<xenc:CipherText>AbCd….wXYZ</xenc:CipherText>

</xenc:EncryptedData>

</foo>

</root>

5.6 Encrypting the content of an XML element

When encrypting the content of an XML element, replace the children of the element containing the content to be encrypted with a single <EncryptedData> element. The <CipherText> is the encrypted string formed by serializing the element's children. For example, this plaintext XML

<root>

<foo>

<a/>

</ElementWithToBeEncrypted>

</element>

</root>

becomes

<root>

<foo>

<xenc:EncryptedData xmlns:xenc='http://www.w3.org/2000/11/temp-xmlenc’ Type=”NodeList”>

<xenc:CipherText>AbCd….wXYZ</xenc:CipherText>

</xenc:EncryptedData>

</ElementWithContentToBeEncrypted>

</foo>

</root>

5.7 Encrypting an entire XML document

When encrypting an entire XML document, replace the document with an <EncryptedData> element. The <CipherText> is the encrypted string formed by serializing the document starting from its prolog to the end tag of the root element, inclusively. For example, this plaintext XML

<root>

...

</root>

becomes

<xenc:EncryptedData xmlns:xenc='http://www.w3.org/2000/11/temp-xmlenc’ Type=”NodeList”>

<xenc:CipherText>AbCd….wXYZ</xenc:CipherText>

</xenc:EncryptedData>

5.8 Encrypting external data reference by an XML element

When encrypting external data referenced by an XML element, create an <EncryptedData> element for each reference and insert these <EncryptedData> element as children of the referencing element. For example,

<smil>

...

...

</smil>

becomes (after the MPEG has been encrypted and stored in "secret.enc" (and secret.mpg deleted): )

<smil>

...

<xenc:EncryptedData xmlns:xenc='http://www.w3.org/2000/11/temp-xmlenc’ Type=”video/mpeg” smil:Name=”secret.mpg”>

<xenc:CipherText xenc:URI=”http:www.example.com/videos/secret.enc”/>

</xenc:EncryptedData>

...

</smil>

In some instances, applications encrypting external data may wish to express linkage between their notion of objects and the EncryptedData elements. One possible approach, as shown above, is to use an application defined attribute on the EncryptedData element. This needs further discussion to determine the best approach (see Section 8).

6 Algorithms

This section identifies algorithms used with the XML encryption standard. Entries contain the identifier to be used in encrypted documents, a reference to the formal specification, and definitions, where applicable, for the representation of keys and the results of cryptographic operations.

6.1 Algorithm Identifiers and Requirements

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

Block Encryption:

AES

AES with 128-bit key in CBC mode with PKCS#5 padding REQUIRED

urn:nist-gov:aes-128-cbc

AES with 192-bit key in CBC mode with PKCS#5 padding OPTIONAL

urn:nist-gov:aes-192-cbc

AES with 256-bit key in CBC mode with PKCS#5 padding REQUIRED

urn:nist-gov:aes-256-cbc

Triple DES

Three key Triple DES using EDE in CBC mode with PKCS#5 padding

OPTIONAL

urn:nist-gov:tripledes-ede-cbc

Key Transport Algorithms

RSA

RSA using v1.5 padding OPTIONAL

urn:rsadsi-com:rsa-v1.5

RSA using v2.0 (OAEP) padding REQUIRED

urn:rsadsi-com:rsa-v2.0

Symmetric Key Wrap Algorithms

AES warp algorithm TBD

uri TBD

CMS Triple-DES Key wrap algorithm OPTIONAL

urn:ietf-org:cms-tripledes-keywrap

6.2 Block Encryption

6.2.1 AES

The AES <....> algorithm identifier is urn:nist-gov:aes-XXX-YYY where XXX represents the size of the key in bits and YYY represents the chaining mode used. For the purposes of this document XXX is restricted to 128, 192 and 256 bit keys and YYY is restricted to CBC mode. The AES algorithm takes one optional parameter containing the Initialization Vector (IV). An example of an AES EncryptionMethod element:

<EncryptionMethod Algorithm="urn:nist-gov:aes-128-cbc"><IV>abcdefghij</IV></EncryptionMethod>

6.2.1 Triple DES

The TripleDES <...> algorithm identifier is "urn:nist-gov:tripledes-ede-YYY" where YYY represents the chaining mode used. For the purposes of this document YYY is restricted to CBC mode. The TripleDES algorithm takes one optional parameter containing the Initialization Vector (IV). An example of a TripleDes EncryptionMethod element:

<EncryptionMethod ALgorithm="urn:nist-gov:tripledes-ede-cbc"><IV>abcdefghij</IV></EncryptionMethod>

6.3 Key Transport Algorithms

6.3.1 RSA

When using RSA for encrypting keying material or data, the algorithm identifier is “urn:rsadsi-com:rsa-v1.5” for PKCS#1 with version 1.5 padding and “urn”rsadsi-com:rsa-v2.0” for PKCS#1 with version 2.0 (OAEP) padding.

6.4 Key Wrap Algorithms

6.4.1 AES KeyWrap

TBD

6.4.2 TripleDES KeyWrap

The algorithm specified by the IETF CMS for wrapping of TripleDES and RC2 keys is optional. It is anticipated that an AES key wrapping algorithm will be specified prior to approval of this specification.

The CMS KeyWrap algorithm is simple and has been implemented by several different groups of people and is currently used for S/MIME ES-DH key agreement key wrapping.

7 Schema

<!DOCTYPE schema

PUBLIC "-//W3C//DTD XMLSCHEMA 200010//EN" http://www.w3.org/2000/10/XMLSchema.dtd

[

<!ATTLIST schema xmlns:ds CDATA #FIXED "http://www.w3.org/2000/10/XMLSchema">

<!ENTITY enc "http://www.w3.org/2000/11/temp-xmlenc">

<!ENTITY enc 'http://www.w3.org/2000/11/xmlenc#'>

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

<schema xmlns="http://www.w3.org/2000/10/XMLSchema"

xmlns:ds="&dsig;"

xmlns:xenc=”&enc;”

targetNamespace="&enc;"

version="0.1"

elementFormDefault="qualified">

</sequence>

</complexType>

</element>

</sequence>

</complexType>

</element>

</sequence>

</complexType>

</element>

</sequence>

</complexType>

</element>

</sequence>

</complexType>

</element>

</sequence>

</complexType>

</element>

</sequence>

</complexType>

</element>

</choice>

</complexType>

</element>

</sequence>

</complexType>

</element>

</schema>

8 Open Issues

1. To support encryption of keying material to multiple recipients within a single EncryptedKey element, one could use the alternative EncryptedKey schema shown below:

<ReferenceList>?

<EncrytionMethod>?

<KeyInfo>?

<CipherText>?

</Recipient>+

</Recipients>

</EncryptedKey>

The authors question whether this extra complexity is justified.

2. Applications encrypting external data may wish to express linkage between their objects and the EncryptedData elements. This could, for example, allow one to indicate when EncryptedData’s represent different encodings of the same object or perhaps some ordered components (e.g., Chapters) of an object. Possible approaches to this include:

· Do not address in this spec. By implication, the application must place the EncryptedData elements inside application-defined structures that express such semantics.

· Define a generic attribute (e.g., Name) in the encryption namespace that applications may use for this purpose

· Allow attributes in any namespace to be added to an EncryptedData for this purpose.

3. This specification does not define syntax for specifying an encryption key, using only key attributes, along with an associated reference list pointing to the data encrypted with that key. This could be used, for example, to specify a symmetric encryption key by name (using the KeyInfo element) along with a set of references to all the EncryptedData elements encrypted using that key. With the current design, one would place the key name information inside each of the EncryptedData elements.

The issue is whether this specification should define additional syntax supporting this semantic? Such a syntax might look like:

</sequence>

</complexType>

</element>

It has also been noted that this semantic can be handled by the using application with whatever encoding they find convenient. Hence, such a syntax is not essential.

4. There has been considerable discussion amongst the authors as to the best syntax for expressing key sharing semantics. Two approaches have been seriously discussed. One of the approaches is represented by the syntax specified in this document. Using this syntax, an EncryptedData may contain EncryptedKey and/or KeyInfo child elements. The EncryptedKey element may also contain a KeyInfo child element. A KeyInfo may not contain an EncryptedKey child element, though a reference to an EncryptedKey is allowed within an EncryptedData element context.

The alternate proposal is to only allow an EncryptedKey element as a child of a KeyInfo element. Both approaches seem to offer sufficient semantic richness for real-world application needs. Though we should investigate further whether certain applications make one of these approaches preferable.

The alternate proposal does offer some degree of syntactic simplification. Key sharing information inside an EncryptedData would always be encoded using a KeyInfo element, so a discussion of how KeyInfo and EncryptedKey sibling elements relate is unnecessary. There may also be benefits in allowing implicit linkages between encryption keys via element nesting as opposed to the explicit references required by the current design. On the other hand, the alternate syntax allows unbounded nesting of the form:

...

This may have negative implications for building conformant decryption tools, though one can also construct pathological examples using the current syntax that may be equally problematic.

Both designs need more thorough analysis and review before resolving this issue.

5. It has been noted by Hal Finney, Steve Wiley, et al that encrypting XML raises concerns over attacks based on known plaintext as well as known length of the encrypted plaintext. This issue, in regards to encrypting enumerated attributes values, is one reason for not supporting attribute-value encryption. But, it remains an issue with Elements or NodeList fragments. Specifically, the attacker may know the XML schema for the encrypted data and the plaintext may consist primarily of element tags with short variable values of known length. For example:

</AccountInfo>

If the AccountType value is one character from a small know set, and the AccountNumber value is 6 digits, it is trivial to enumerate the possible plaintexts. Furthermore, the encrypted octet sequence length will typically be the plaintext size rounded up to the nearest multiple of the cipher block size. This may help in guessing the structure of the plaintext data even if some variability is possible. To address this, one could introduce required padding when encrypting Elements or NodeLists. Use of a prepended string of non-zero random bytes, followed by a zero byte, and then the plaintext to be encrypted similar to PKCS-1 v1.5 is one suggested approach. It needs to be determined if such padding should be defined by this specification and whether its use is mandatory or recommended.

6. The XML schema presented in Section 7 still needs to be thoroughly reviewed for conformance with [XML-schema].

9 References

[3DES] ANSI. Triple Data Encryption Algorithm Modes of Operation, ANSI X9.52, 1998.

[AES] Joan Daemen and Vincent Rijmen. AES Proposal: Rijndael, 2000.

[C14N] John Boyer. Canonical XML Version 1.0, W3C Candidate Rec., 2000.

[CMS] Russell Housley. Cryptographic Message Syntax, RFC 2630, 1999.

[DSIG] Donald Eastlake, Joseph Reagle, and David Solo. XML-Signature Syntax and Processing, W3C Working Draft, 2000.

[ESDH]Eric Rescorla. Diffie-Hellman Key Agreement Method, RFC 2631, 1999.

[INFOSET] John Cowan. XML Information Set, W3C Working Draft, 2000.

[MIME] Ned Freed and Nathaniel Borenstein. Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies, RFC 2045, 1996.

[NOTE] Takeshi Imamura and Hiroshi Maruyama. Note on XML Encryption, 2000.

[NS] Tim Bray, Dave Hollander, and Andrew Layman. Namespaces in XML, W3C Rec., 1999.

[PKCS1] RSA Laboratories. PKCS #1 v2.0: RSA Cryptography Standard, 1998.

[PKCS5] RSA Laboratories. PKCS #5 v2.0: Password-Based Cryptography Standard, 1999.

[PKCS7] Burt Kaliski. PKCS #7: Cryptographic Message Syntax Version 1.5, RFC2315, 1998.

[PROP1] Ed Simon and Brian LaMacchia. XML Encryption Syntax and Processing, 2000.

[PROP2] Takeshi Imamura and Hiroshi Maruyama. Specification of Element-wise XML Encryption, 2000.

[REQ] Hiroshi Maruyama and Takeshi Imamura. Element-wise XML Encryption, 2000.

[ XML-schema] XML Schema Part 1: Structures Working Draft. D. Beech, M. Maloney, N. Mendelshohn. September 2000. XML Schema Part 2: Datatypes Working Draft. P. Biron, A. Malhotra. September 2000.