Copyright © 2001 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document specifies a process for encrypting data and representing the result in XML. The data may be arbitrary binary data, an XML document, an XML element, or its content. When an element is encrypted, the element is replaced with an XML Encryption element. Otherwise, the encryption element serves as the root of the new document.
This is an editors' copy that has absolutely no standing.
This document specifies a process for encrypting data and representing the result in XML. The data may be arbitrary binary data, an XML document, or an XML element. When an element is encrypted, the element is replaced with an XML Encryption element. Otherwise the encryption element serves as the root of the new document.
This specification uses XML Schemas [XML-schema] to describe the content model.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in RFC2119 [KEYWORDS]:
"they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)"
Consequently, we use these capitalized keywords to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. These key words are not used (capitalized) to describe XML grammar; schema definitions unambiguously describe such requirements and we wish to reserve the prominence of these terms for the natural language descriptions of protocols and features. For instance, an XML attribute might be described as being "optional." Compliance with the XML-namespace specification [XML-NS] is described as "REQUIRED."
The design philosophy and requirements of this specification are addressed in the XML Encryption Requirements document [EncReq].
No provision is made for an explicit version number in this syntax. If a future version is needed, it will use a different namespace. The experimental XML namespace [XML-NS] URI that MUST be used by implementations of this (dated) specification is:
enc:xmlns='http://www.w3.org/2001/04/xmlenc#'
Additionally, this specification makes use of the XML Signature [XMLDSIG] namespace and schema definitions
xmlns:ds='http://www.w3.org/2000/09/xmldsig#'
This namespace is also used as the prefix for algorithm identifiers used by this specification. While applications MUST support XML and XML namespaces, the use of internal entities [XML] or our "enc" XML namespace prefix and defaulting/scoping conventions are OPTIONAL; we use these facilities to provide compact and readable examples.
The contributions of the following working group members to this specification are gratefully acknowledged:
...
This section provides an overview and examples of XML Encryption syntax. The formal syntax is found in Core Encryption Syntax (section 3); the specific processing is given in Processing Rules (section 4).
Data (XML documents, elements, or binary data) that is encrypted according to this specification is removed, encrypted, encoded, and replaced with an EncryptedData element. The EncryptedData element has the following structure:
<EncryptedData Id='' Type=''>
<EncryptionMethod/>
<KeyInfo>
<EncryptedKey/>
<KeyRetrievalMethod/>
</KeyInfo>?
<CipherData URI=''>iamscrambled</CipherData>
</EncryptedData>
Consider the following fictitious payment information
<?xml version='1.0'?>
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith<Name/>
<Card Limit='5,000' Currency='USD'>
<Number>4019 2445 0277
5567</Number>
<Issuer>Bank of the
Internet</Issuer>
<Expiration>04/02</Expiration>
</Card>
</PaymentInfo>
This markup conveys that the characteristics of John Smith's credit card with a limit of $5,000USD.
Smith's credit card number is sensitive information! If the
application wishes to keep that information confidential, it can
encrypt the Card element.
<?xml version='1.0'?>
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith<Name/>
<EncryptedData
Type='http://www.w3.org/2001/04/xmlenc#Element'
xmlns='http://www.w3.org/2001/04/xmlenc#'>
<CipherData>A23B45C56</enc:CipherData>
</EncryptedData>
</PaymentInfo>
The CipherData contains the encrypted serialization of the
Card element.
Unfortunately, some agents of the processing scenario need to
know John's credit limit, but they do not need his credit card
number. In this case, the content (character data or children
elements) of the Card element is encrypted:
<?xml version='1.0'?>
<PaymentInfo xmlns='http://example.org/paymentv2'>
<Name>John Smith<Name/>
<Card Limit='5,000' Currency='USD'>
<EncryptedData Type='http://www.w3.org/2001/04/xmlenc#ElementChildNodeList'
xmlns='http://www.w3.org/2001/04/xmlenc#'>
<CipherData>A23B45C56</CipherData>
</EncryptedData>
</Card>
</PaymentInfo>
If the application scenario requires all of the information to be encrypted the whole document is encrypted as an octet set. This applies to arbitrary data including XML documents.
<?xml version='1.0'?> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.isi.edu/in-notes/iana/assignments/media-types/text/xml'> <CipherData>A23B45C56</CipherData> </EncryptedData>
An XML document may contain zero or more EncryptedData elements.
However, EncryptedData can not be the parent or child of another
EncryptedData element -- though the data encrypted by this element
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, will result in invalid XML
against the schema defined in this specification.
For example, consider the following:
<pay:PaymentInfo xmlns:pay='http://example.org/paymentv2'>
<EncryptedData ID='ED1' Type='http://www.w3.org/2001/04/xmlenc#Element'
xmlns='http://www.w3.org/2001/04/xmlenc#'>
<CipherData>originalEncryptedData</enc:CipherData>
</EncryptedData>
</pay:PaymentInfo>
A valid super-encryption of
'//EncryptedData[@Id='ED1']' would be:
<pay:PaymentInfo xmlns:pay='http://example.org/paymentv2'>
<EncryptedData ID='ED2' Type='http://www.w3.org/2001/04/xmlenc#EncrypedData'
xmlns='http://www.w3.org/2001/04/xmlenc#'>
<CipherData>newEncryptedData</enc:CipherData>
</EncryptedData>
</pay:PaymentInfo>
where 'newEncryptedData' is the base64 encoding of
the encrypted octet sequence resulting from encrypting the
EncryptedData element with Id='ED1'.
[s1] <EncryptedData
xmlns='http://www.w3.org/2001/04/xmlenc#’
Type='http://www.w3.org/2001/04/xmlenc#Element'/>
[s3] <EncryptionMethod
Algorithm='urn:nist-gov:tripledes-ede-cbc'/>
[s4] <KeyInfo>
[s5] <ds:KeyName
xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>
John
Smith
</ds:KeyName>
[s6] </KeyInfo>
[s7]
<CipherData>DEADBEEF</CipherData>
[s8] </EncryptedData>
[s1] The type of data encrypted may be represented
as an attribute value as an aid in decryption and subsequent
processing. In this case, the data encrypted was an element. Other
alternatives include the childNodes [DOM] of an element, or an an
external octet sequence that is identified by a media type URI.
[s2] This (3DES CBC) is a symmetric key cipher.
[s3-s4] The symmetric key has the name John
Smith.
[s6] CipherData will always be a base64 encoded
octet sequence or a URI reference with any transforms necessary to
obtain the cipher data as an octet sequence.
The following EncryptedData structure is very similar to the one above, except this time the key is referenced using a KeyRetrievalMethod:
[t01] <EncryptedData Id='ED' xmlns:enc='http://www.w3.org/2001/04/xmlenc#’> [t02] <EncryptionMethod Algorithm='urn:nist-gov:aes-128-cbc'/> [t03] <KeyInfo xmlns:ds=’http://www.w3.org/2000/09/xmldsig#’> [t04] <KeyRetrievalMethod URI='#EK'/> [t05] <NameKey>John Doe</NameKey> [t06] </KeyInfo> [t07] <CipherData>DEADBEEF</CipherData> [t08] </EncryptedData>
[t02] This (AES-128-CBC) is a symmetric key
cipher.
[t03] The (AES) key is located at '#EK'.
[t04] KeyRetrievalMethod is analogous to the
ds:RetrievalMethod except that the type of the referent is always
of type EncryptedKey:
[t05] NameKey is the name associated with the
symmetric key found at the KeyRetrievalMethod. (?)
[t09] <enc:EncryptedKey Id='EK'
[t10]
xmlns:enc='http://www.w3.org/2001/04/xmlenc#’>
[t11] <enc:EncryptionMethod Algorithm='
urn:rsadsi-com:rsa-v2.0'/>
[t12] <enc:ReferenceList>
[t13] <enc:DataReference
URI='#ED'/>
[t14] </enc:ReferenceList>
[t15] <enc:KeyInfo
xmlns:ds=’http://www.w3.org/2000/09/xmldsig#’>
[t16] <ds:KeyName>John
Doe</ds:KeyName>
[t17] </enc:KeyInfo>
[t18]
<enc:CipherData>xyzabc</enc:CipherData>
[t19] </enc:EncryptedKey>
[t09] The EncryptedKey element is very similar to
that of EncryptedData except that it's always encrypted a key
value. Frequently, the recipients public key is used to encrypt a
symmetric key.
[t11] The EncryptionMethod is the RSA public key
algorithm.
[t12-14] A ReferenceList identifies the encrypted
objects (DataReference and KeyReference) encrypted with this
key.
[t16] The CipherData is encrypted in RSA public key
named 'John Doe' The ReferenceList contains a list of
references to data encrypted by the symmetric key carried within
this structure.
[t18] The CipherData is an octet sequence that is
encoded (e.g., padded) by a referring encrypted object's
EncryptionMethod. (Note, an EncryptedKey's EncryptionMethod is the
algorithm used to encrypt these octets and does not speak about
what type of octets they are.)
This section provides a detailed description of the syntax and features for XML Encryption. Features described in this section are mandatory to implement unless otherwise noted. The syntax is defined via [XML-Schema] with the following XML preamble, declaration, internal entity, and import:
<?xml version='1.0'?>
<!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/09/xmldsig#'>
<!ATTLIST schema
xmlns:enc CDATA #FIXED 'http://www.w3.org/2001/04/xmlenc#'>
]>
<schema xmlns='http://www.w3.org/2000/10/XMLSchema' version='0.1'
xmlns:ds='http://www.w3.org/2000/09/xmldsig#'
xmlns:enc='http://www.w3.org/2001/04/xmlenc#'
targetNamespace='http://www.w3.org/2001/04/xmlenc#'
elementFormDefault='qualified'>
<import namespace='http://www.w3.org/2000/09/xmldsig#'
schemaLocation='xmldsig-core-schema.xsd'/>
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 usef ul to processing.
<complexType name='EncryptedType' abstract='true'>
<sequence>
<!-- this shows an enc:element being of ds:type -->
<element name='EncryptionMethod' type='ds:DigestMethodType' minOccurs='0'/>
<!-- this shows a enc:type being extended from ds:type -->
<element ref='enc:KeyInfo' minOccurs='0'/>
<element ref='enc:CipherData'/>
</sequence>
<attribute name='Id' type='ID' use='optional'/>
</complexType>
EncryptionMethod is an optional element that describes the encryption algorithm applied to the CipherData contained in this element. If the element is absent, the encryption algorithm assumed to be known by the recipient.
KeyInfo is an optional element, defined by [XMLDSIG], that carries information about the key used to encrypt the CipherData. The new elements defined by this specification that may appear a children of KeyInfo are described in the subsequent sections.
CipherData 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.
The CipherData is a mandatory element that provides the
encrypted data. It may either contain the encrypted octet sequence
as base64 encoded text or provide a reference to an external
location (subject to the same processing rules as
ds:TransformsType) containing the encrypted octet
sequence.
<element name='CipherData' type='ds:CryptoBinary'/>
or
<element name='CipherData'>
<complexType>
<choice>
<element ref='ds:Transforms' minOccurs='0'/>
</choice>
</complexType>
<attribute name='URI' type='uriReference' use='required'/>
</element>
This isn't valid schema. We need a schema construct that has the content (or a child with the content) of CryptoBinary, *or* a set of transforms. -- Reagle/Dillaway.
The EncryptedData element is the core element in the syntax. Not only does its CipherData child contain the encrypted data, but it's also the element that replaces the encrypted element, or serves as the new document root.
<element name='EncryptedData' type='enc:EncryptedDataType'/>
<complexType name='EncryptedDataType'>
<complexContent>
<extension base='enc:EncryptedType'>
<attribute name='Type' type='uriReference' use='optional'/>
</extension>
</complexContent>
</complexType>
Type is an optional attribute identifying type information about the decrypted content.
There are different ways to define the key material to be used in decrypting the CipherData. In all cases, this information is contained within a KeyInfo element.
This specification defines two elements that may be used as children of the enc:KeyInfo element. These are the EncryptedKey and KeyRetrievalMethod elements described in subsequent sections.
<element name='KeyInfo' type='enc:KeyInfoType'/>
<complexType name='KeyInfoType'>
<complexContent>
<extension base='enc:KeyInfoType'>
<sequence>
<element name='EncryptedKey' minOccurs='0'
maxOccurs='unbounded'/>
<element ref='enc:KeyRetrievalMethod'
minOccurs='0' maxOccurs='unbounded'/>
</sequence>
</extension>
</complexContent>
</complexType>
This is presently broken as validators will complain of ambiguous content models. I'm working on understanding this, and it relates to the question of should create a derived enc:KeyInfoType element based in enc:KeyInfoType, create a enc:KeyInfo based on enc:KeyInfoType, or just use ds:KeyInfo? -- Reagle
The EncryptedKey element is used to transport encryption keys from the originator to a known recipient(s). It may be used as a standalone XML document, be placed within an application document, or appear inside an EncryptedData element as a child of a KeyInfo element. The key value is always encrypted to the recipient(s).
<element name='EncryptedKey' type='enc:EncryptedKeyType'/>
<complexType name='EncryptedKeyType'>
<complexContent>
<extension base='enc:EncryptedType'>
<sequence>
<element ref='enc:ReferenceList' minOccurs='0'/>
</sequence>
<attribute name='NameKey' type='string' use='optional'/>
<attribute name='Recipient' type='string' use='optional'/>
</extension>
</complexContent>
</complexType>
ReferenceList is an optional element containing pointers to data and keys encrypted using this key. The reference list may contain multiple references to EncryptedKey and EncryptedData elements. This is done using KeyReference and DataReference elements repectively. These are defined below.
NameKey is an optional attribute for associating a user readable name with the key value. This may then be used to reference the key using the KeyName element within KeyInfo. 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 within a single XML document
Recipient is an optional attribute that contains a hint as to which recipient this encrypted key value is intended for. Its contents are application dependent.
The KeyRetrievalMethod element provides a way to express a link from an EncryptedData element to the EncryptedKey element containing the key used needed to decrypt it. The KeyRetrievalMethod element may occur multiple times within a KeyInfo element referring to different EncryptedKey objects containing the same key value but encrypted in different ways or for different recipients.
<element name='KeyRetrievalMethod' type='enc:KeyRetrievalMethodType'
substitutionGroup='ds:RetrievalMethod' />
<complexType name='KeyRetrievalMethodType'>
<complexContent>
<restriction base='ds:RetrievalMethodType'>
<sequence>
<element name='Transforms' type='ds:TransformsType' minOccurs='0'/>
</sequence>
<attribute name='URI' type='uriReference'/>
<attribute name='Type' type='uriReference'
use='fixed' value='http://www.w3.org/2001/04/xmlenc#EncryptedKey'/>
</restriction>
</complexContent>
</complexType>
KeyRetrievalMethod uses similar syntax and dereferencing behavior to the RetrievalMethod element in [XMLDSIG], except the type attribute is always fixed to be of type EncryptedKey.
ReferenceList is an element that contains pointers from a key to encrypted data (ordinary data or EncryptedKeys).
<element name='ReferenceList'>
<complexType>
<sequence>
<element name='DataReference' type='enc:ReferenceType'
minOccurs='0' maxOccurs='unbounded'/>
<element name='KeyReference' type='enc:ReferenceType'
minOccurs='0' maxOccurs='unbounded'/>
</sequence>
</complexType>
</element>
<complexType name='ReferenceType'>
<sequence>
<any namespace='##other' minOccurs='0' maxOccurs='unbounded'/>
</sequence>
<attribute name='URI' type='uriReference' use='optional'/>
</complexType>
DataReference elements are used to refer to EncryptedData elements that were encrypted using the key defined in the enclosing EncryptedKey element. Multiple DataReference elements can occur if multiple EncryptedData elements exist that are encrypted by the same key.
KeyReference elements are used to refer to EncryptedKey objects that were encrypted using the key defined in the enclosing EncryptedKey element. Multiple KeyReference elements can occur if multiple EncryptedKey elements exist that are encrypted by the same key.
For both types of references one may optionally specify child elements to aid the recipient in retrieving the EncryptedKey and/or EncryptedData elements. These could include information such as XPath transforms, decompression transforms, or information on how to retrieve the objects from a document storage facility.
This section describes the operations to be performed as part of encryption and decryption processing.
For each data item or key to be encrypted:
For each item to be decrypted (either an EncryptedData or EncryptedKey element):
The specification above presumes that the data to be encrypted
is processed as an octet string. The application is responsible for
serializing the XML into an octet string that will be useful
subsequent to decryption. For instance, if the applications wishes
to canonicalize (using [XML-C14N] or some other serialization) or
encode/compress the data in an XML packaging format, the
application needs to marshal the XML accordingly and identify the
resulting type with optional the EncryptedData
type attribute. The likelihood of interoperable decryption
and subsequent use will be dependent on the decryptors support for
a given type. Also, if the data is intended to be processed both
before and after decryption (e.g., XML Signature validation or XSLT
transform) the encryptor must be careful to preserve information
necessary for that process's success.
For interoperability purposes, the following types MUST be implemented.
Element interface
represents an
element in an HTML or XML document.... the
Element interface inherits from
Node, the generic
Node interface..."
Element,
Text,
Comment,
ProcessingInstruction,
CDATASection,
EntityReference"This specification is still very rough and experimental.
Data Model: DOM extends the InfoSet model and can preserve CDATA and external entity references. Unfortunately, DOM doesn't have an equivalent of the Information Set [in-scope namespaces] which gives you a list of all prefixes+namespaces in effect for that node. (DOM can give you all the namespaces for a node (those declared in the node and its ancestors), but not the prefixes+namespaces.)
Identifiers: There are no published URIs for these types, so this specification defines its own identifiers (for DOM or InfoSet) in the XML Encryption namespace.
TDB
The application of both encryption and digital signatures over portions of an XML document can make subsequent decryption and signature verification difficult. In particular, when verifying a signature one must be know whether the signature was computed over the encrypted or unencrypted representation of elements.
A separate, but important, issue is introducing cryptographic vulnerabilities when combining digital signatures and encryption over a common XML element. Hal Finney has suggested that encrypting digitally signed data, while leaving the digital signature in the clear, may allow plaintext guessing attacks.
In accordance with the requirements document [EncReq] the interaction of encryption and signing is an application issue and out of scope of the specification. However, we make the following recommendations:
Where a symmetric key is shared amongst multiple recipients, its encapsulating EncryptedKey should not reference or be referenced by other data not intended for all of those multiple recipients. (Kind of complex...?)
Where a symmetric key is shared amongst multiple recipients, that symmetric key should *only* be used for the data intended for those multiple recipients. (Quite strong.)
...