Please refer to the errata for this document, which may include some normative corrections.
The English version of this specification is the only normative version. Non-normative translations may also be available.
Copyright © 2013 W3C® (MIT, ERCIM, Keio, Beihang), All Rights Reserved. W3C liability, trademark and document use rules apply.
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.
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). All comments are welcome.
This document was produced by a group operating under the 5 February 2004 W3C Patent Policy. 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.
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.
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".
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].
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:
URI | namespace prefix | XML 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]:
URI | namespace prefix | XML 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#"> |
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.
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 ):
<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
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):
<?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.
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:
<?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.
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:
<?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>
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:
<?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.
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.
<?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:
<?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>
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:
<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:
<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'
.
EncryptedData
and EncryptedKey
UsageEncryptedData
with Symmetric Key (KeyName
)[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
EncryptedKey
(ReferenceList
, ds:RetrievalMethod
,
CarriedKeyName
)The following EncryptedData
structure is very similar to the
one above, except this time the key is referenced using a
ds:RetrievalMethod
:
[t01]<EncryptedData Id="ED" xmlns="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]
:
[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.)
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"/>
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"/>
EncryptedType
ElementEncryptedType
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.
EncryptionMethod
ElementEncryptionMethod 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.)
CipherData
ElementThe 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>
CipherReference
ElementIf 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:
<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>
EncryptedData
ElementThe 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>
ds:KeyInfo
ElementThere are three ways that the keying material needed to decrypt
CipherData
can be provided:
EncryptedData
or 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:
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.)ds:KeyName
to refer to an
EncryptedKey
CarriedKeyName
is
RECOMMENDED.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).
ds:KeyInfo
)
EncryptedKey
element can specify the
EncryptedData
or EncryptedKey
to which its
decrypted key will apply via a DataReference
or
KeyReference
(
section 3.6 The ReferenceList Element).
EncryptedKey
ElementType="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.)
DerivedKey
ElementType="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
or
Signature
element as a child of a ds:KeyInfo
element. The key value itself is never sent by the
originator. Rather, the originator provides information to the
recipient(s) by which the recipient(s) can derive the same key
value. When the key has been derived the resulting octets are made
available to the EncryptionMethod
or
SignatureMethod
algorithm without any additional
processing.
Schema Definition:
<!-- targetNamespace='http://www.w3.org/2009/xmlenc11#' --> <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.
ds:RetrievalMethod
ElementThe 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.
ReferenceList
ElementReferenceList
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
key.
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
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 elements from a document storage facility. For example:
<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>
EncryptionProperties
ElementType="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 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.
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:
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.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 for 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.
Type
parameter valuesFor 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]:
EmptyElemTag
| STag
content
ETag"CharData
?
((element
| Reference
| CDSect
| PI |
Comment)
CharData
?)*"Support for the following type is OPTIONAL for Encryptors and Decryptors:
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.
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:
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
").
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,
etc.
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.
For each EncryptedData
or EncryptedKey
to be decrypted,
the decryptor MUST:
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].
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:
Where X is the [XPATH] node set
corresponding to an XML document and e is an
EncryptedData
element node in X.
EncryptedData
element type. In which case:
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:
<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:
<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:
<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:
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.
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:
<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:
<Baz xml:base="http://example.org/"/>
the result will be:
<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.
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:
<!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:
<!DOCTYPE dummy [ <!ENTITY dsig "http://www.w3.org/2000/09/xmldsig#"> ]> <dummy xmlns="http://example.org/" xmlns:foo="http://example.org/foo"> <One> <foo:Two/> </One> </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.
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.
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.
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.
*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).
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.
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
.
NIST SP800-67 [SP800-67] specifies three sequential FIPS 46-3 [DES] operations. The XML Encryption TRIPLEDES consists of a DES encrypt, a DES decrypt, and a DES encrypt used in the Cipher Block Chaining (CBC) mode with 192 bits of key and a 64 bit Initialization Vector (IV). Of the key bits, the first 64 are used in the first DES operation, the second 64 bits in the middle DES operation, and the third 64 bits in the last DES operation.
Note: Each of these 64 bits of key contain 56 effective bits and 8 parity bits. Thus there are only 168 operational bits out of the 192 being transported for a TRIPLEDES key. (Depending on the criterion used for analysis, the effective strength of the key may be thought to be 112 bits (due to meet in the middle attacks) or even less.)
The resulting cipher text is prefixed by the IV. If included in XML output, it is then base64 encoded. An example TRIPLEDES EncryptionMethod is as follows:
<EncryptionMethod Algorithm="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.
[AES] is used in the Cipher Block Chaining (CBC) mode with a 128 bit initialization vector (IV). The resulting cipher text is prefixed by the IV. If included in XML output, it is then base64 encoded. An example AES EncryptionMethod is as follows:
<EncryptionMethod Algorithm="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.
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].
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>
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.
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='http://www.w3.org/2009/xmlenc11#' --> <!-- use this element type as a child of xenc11:KeyDerivationMethod when used with ConcatKDF --> <element name="ConcatKDFParams" type="xenc11:ConcatKDFParamsType"/> <complexType name="ConcatKDFParamsType"> <sequence> <element ref="ds:DigestMethod"/> </sequence> <attribute name="AlgorithmID" type="hexBinary"/> <attribute name="PartyUInfo" type="hexBinary"/> <attribute name="PartyVInfo" type="hexBinary"/> <attribute name="SuppPubInfo" type="hexBinary"/> <attribute name="SuppPrivInfo" type="hexBinary"/> </complexType>
The ds:DigestMethod
element identifies the digest
algorithm used by the KDF. Compliant implementations MUST support
SHA-256 and SHA-1 (support for SHA-1 is present only for
backwards-compatibility reasons). Support for SHA-384 and SHA-512 is
OPTIONAL.
The AlgorithmID
, PartyUInfo
,
PartyVInfo
, SuppPubInfo
and
SuppPrivInfo
attributes are as defined in
[SP800-56A]. Their
presence is optional but AlgorithmID
,
PartyVInfo
and PartyUInfo
MUST be present
for applications that need to comply with [SP800-56A].
Note: The PartyUInfo
component shall include a nonce when
ConcatKDF is
used in conjunction with a static-static Diffie-Hellman (or
static-static ECDH) key agreement scheme; see further [SP800-56A].
In [SP800-56A], AlgorithmID
, PartyUInfo
, PartyVInfo
, SuppPubInfo
and
SuppPrivInfo
attributes are all defined as
arbitrary-length bitstrings, thus they may need to be padded in order
to be encoded into hexBinary for XML Encryption. The following
padding and encoding method MUST be used when encoding bitstring
values for the AlgorithmID
, PartyUInfo
,
PartyVInfo
, SuppPubInfo
and
SuppPrivInfo
:
The bitstring is divided into octets using big-endian encoding. If the length of the bitstring is not a multiple of 8 then add padding bits (value 0) as necessary to the last octet to make it a multiple of 8.
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
:
<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>
The PBKDF2 key derivation algorithm and the ASN.1 type definitions for
its parameters are defined in PKCS #5 v2.0 [PKCS5]. The XML schema
definitions for the parameters is defined in [PKCS5Amd1] and the same
can be specified by enclosing them within an xenc11:PBKDF2-params
child
element of the xenc11:KeyDerivationMethod
element.
Schema Definition:
<element name="PBKDF2-params" type="xenc11:PBKDF2ParameterType"/> <complexType name="PBKDF2ParameterType"> <sequence> <element name="Salt"> <complexType> <choice> <element name="Specified" type="base64Binary"/> <element name="OtherSource" type="xenc11:AlgorithmIdentifierType"/> </choice> </complexType> </element> <element name="IterationCount" type="positiveInteger"/> <element name="KeyLength" type="positiveInteger"/> <element name="PRF" type="xenc11:PRFAlgorithmIdentifierType"/> </sequence> </complexType> <complexType name="AlgorithmIdentifierType"> <sequence> <element name="Parameters" type="anyType" minOccurs="0"/> </sequence> <attribute name="Algorithm" type="anyURI"/> </complexType> <complexType name="PRFAlgorithmIdentifierType"> <complexContent> <restriction base="xenc11:AlgorithmIdentifierType"> <attribute name="Algorithm" type="anyURI"/> </restriction> </complexContent> </complexType>
(Note: A newline has been added to the Algorithm attribute to fit on this page, but is not part of the URI.)
The PBKDF2-params
element and its child elements have the
same names
and meaning as the corresponding components of
the PBKDF2-params
ASN.1
type in [PKCS5]. Note, in case of ConcatKDF and the Diffie Hellman
legacy KDF, KeyLength
is an implied parameter and needs to be
inferred from the context, but in the case of PBKDF2
the KeyLength
child
element has to be specified, as it has been made a mandatory parameter
to be consistent with PKCS5. For PBKDF2, the inferred key length must
match the specified key length, otherwise it is an error condition.
The AlgorithmIdentifierType
corresponds to
the AlgorithmIdentifier
type of [PKCS5] and carries the
algorithm identifier in the Algorithm
attribute. Algorithm
specific parameters, where applicable, can be specified using
the Parameters
element.
The PRFAlgorithmIdentifierType
is derived from the
AlgorithmIdentifierType
and constrains the choice of
algorithms to those contained in the PBKDF2-PRFs set defined in
[PKCS5]. This type is used to specify a pseudorandom function (PRF)
for PBKDF2. Whereas HMAC-SHA1 is the default PRF algorithm in [PKCS5],
use of HMAC-SHA256 is RECOMMENDED by this specification (see [XMLDSIG-CORE1],
[HMAC]).
An example of an xenc11:DerivedKey
element with this key
derivation algorithm is:
<xenc11:DerivedKey xmlns:xsi="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>
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.)
The RSAES-PKCS1-v1_5 algorithm, specified in RFC 3447 [PKCS1], takes no explicit parameters. An example of an
RSA Version 1.5 EncryptionMethod
element is:
<EncryptionMethod Algorithm="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:
CRYPT ( PAD ( KEY ))
where the padding is of the following special form:
02 | PS* | 00 | key
where "|" is concatenation, "02" and "00" are fixed octets of the corresponding hexadecimal value, PS is a string of strong pseudo-random octets [RANDOM] at least eight octets long, containing no zero octets, and long enough that the value of the quantity being CRYPTed is one octet shorter than the RSA modulus, and "key" is the key being transported. The key is 192 bits for TRIPLEDES and 128, 192, or 256 bits for AES.
Implementations MUST support this key transport algorithm for transporting 192-bit TRIPLEDES keys. Support of this algorithm for transporting other keys is OPTIONAL. RSA-OAEP is RECOMMENDED for the transport of AES keys.
The resulting base64 [RFC2045] string is the value of
the child text node of the CipherData
element, e.g.
<CipherData> <CipherValue>IWijxQjUrcXBYoCei4QxjWo9Kg8D3p9tlWoT4 t0/gyTE96639In0FZFY2/rvP /bMJ01EArmKZsR5VW3rwoPxw=</CipherValue> </CipherData>
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.
MGF1 with SHA1
mask generation function)
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]:
Otherwise the two identifiers define the same usage of the RSA-OAEP algorithm, as follows.
The message digest function SHOULD be specified using the Algorithm
attribute of the ds:DigestMethod
child element
of the xenc:EncryptionMethod
element. If it is not specified, the
default value of SHA1
is to be used.
The optional RSA-OAEP PSourceAlgorithm
parameter value MAY be
explicitly provided by placing the base64 encoded octets in the
xenc:OAEPparams
XML element.
The XML Encryption 1.0 schema definition and description for
the EncryptionMethod
element is in
section 3.2 The EncryptionMethod Element. The following
shows the XML Encryption 1.1 addition for the MGF type:
Schema Definition:
<element name="MGF" type="xenc11:MGFType"/> <complexType name="MGFType"> <complexContent> <restriction base="xenc11:AlgorithmIdentifierType"> <attribute name="Algorithm" type="anyURI" use="required" /> </restriction> </complexContent> </complexType>
An example of an RSA-OAEP element is:
<EncryptionMethod Algorithm="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>
<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:
<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.
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:
<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>
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>
The Diffie-Hellman (DH) key agreement protocol [ESDH] involves the derivation of shared secret
information based on compatible DH keys from the sender and recipient. Two DH
public keys are compatible if they have the same prime and generator. If, for
the second one, Y = g**y mod p
, then the two parties can
calculate the shared secret ZZ = ( g**(x*y) mod p )
even though
each knows only their own private key and the other party's public key.
Leading zero bytes MUST be maintained in ZZ
so it will be the
same length, in bytes, as p
. The size of p
MUST be
at least 512 bits and g
at least 160 bits. There are numerous
other complex security considerations in the selection of g
,
p
, and a random x
as described in [ESDH].
The Diffie-Hellman shared secret zz
is used as the input to a KDF to produce a
secret key. XML Signature 1.0 defined a
specific KDF to be used with Diffie-Hellman; that KDF is now known as the "Legacy KDF" and is defined in Section 5.6.2.2.
Use of Diffie-Hellman with explicit KDFs is described in Section 5.6.2.1.
Implementation of Diffie-Hellman key agreement is OPTIONAL. However, if implemented, such implementations MUST support the Legacy Key Derivation Function and SHOULD support Diffie-Hellman with explicit Key Derivation Functions
An example of a DH
AgreementMethod
element using the Legacy Key Derivation Function
(Section 5.6.2.2) is as follows:
<AgreementMethod Algorithm="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>
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:
<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>
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:
Keying Material = KM(1) | KM(2) | ...
where "|" is byte stream concatenation and
KM(counter) = DigestAlg ( ZZ | counter | EncryptionAlg | KA-Nonce | KeySize )
DigestAlg
DigestMethod
child of AgreementMethod
.EncryptionAlg
Algorithm
attribute of the EncryptionMethod
child of the
EncryptedData
or EncryptedKey
grandparent of
AgreementMethod
.KA-Nonce
KA-Nonce
child of
AgreementMethod
, if present. If the KA-Nonce
element is absent, it is null.Counter
KeySize
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
".
SHA-1 ( ZZ01Example:Block/Algfoo80 )
Assuming that ZZ
is 0xDEADBEEF
, that would be
SHA-1( 0xDEADBEEF30314578616D706C653A426C6F636B2F416C67666F6F3830 )
whose value is
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.
ECDH is the elliptic curve analogue to the Diffie-Hellman key agreement algorithm. Details of the ECDH primitive can be found in [ECC-ALGS]. When ECDH is used in Ephemeral-Static (ES) mode, the recipient has a static key pair, but the sender generates a ephemeral key pair for each message. The same ephemeral key may be used when there are multiple recipients that use the same curve parameters.
Compliant implementations are REQUIRED to support ECDH-ES key agreement using the P-256 prime curve specified in Section D.2.3 of FIPS 186-3 [FIPS-186-3]. (This is the same curve that is REQUIRED in XML Signature 1.1 to be supported for the ECDSAwithSHA256 algorithm.) It is further RECOMMENDED that implementations also support the P-384 and P-521 prime curves for ECDH-ES; these curves are defined in Sections D.2.4 and D.2.5 of FIPS 186-3, respectively.
The shared key material is calculated from the Diffie-Hellman shared secret
using a key derivation function (KDF). While applications may define other
KDFs, compliant implementations MUST implement ConcatKDF (see section 5.4.1 ConcatKDF).
An example of xenc:EncryptedData
using the ECDH-ES key
agreement algorithm with the ConcatKDF key derivation algorithm is as
follows:
<xenc:EncryptedData xmlns:xsi="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.
<EncryptedData |EncryptedKey> <EncryptionMethod Algorithm="@alg1"/> <ds:KeyInfo> <EncryptedKey> <EncryptionMethod Algorithm="@alg2"/> </EncryptedKey> </ds:KeyInfo> </EncryptedData |EncryptedKey>
XML Encryption implementations MUST support TRIPLEDES wrapping of 168 bit keys as described in [CMS-WRAP] and may optionally support TRIPLEDES wrapping of other keys.
An example of a TRIPLEDES Key Wrap EncryptionMethod
element
is as follows:
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-tripledes" />
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.
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.
The SHA-1 algorithm [FIPS-180-3] takes no explicit
parameters. An example of an SHA-1 DigestMethod
element is:
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
A SHA-1 digest is a 160-bit string. The content of the
DigestValue
element shall be the base64 encoding of this bit
string viewed as a 20-octet octet stream. For example, the
DigestValue
element for the message digest:
A9993E36 4706816A BA3E2571 7850C26C 9CD0D89D
from Appendix A of the SHA-1 standard would be:
<DigestValue>qZk NkcGgWq6PiVxeFDCbJzQ2J0=</DigestValue>
The SHA-256 algorithm [FIPS-180-3] takes no explicit
parameters. An example of an SHA-256 DigestMethod
element is:
<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.
The SHA-384 algorithm [FIPS-180-3] takes no explicit
parameters. An example of an SHA-384 DigestMethod
element is:
<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.
The SHA-512 algorithm [FIPS-180-3] takes no explicit
parameters. An example of an SHA-512 DigestMethod
element is:
<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.
The RIPEMD-160 algorithm [RIPEMD-160] takes
no explicit parameters. An example of an RIPEMD-160 DigestMethod
element is:
<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.
A Canonicalization of XML is a method of consistently serializing XML into an octet stream as is necessary prior to encrypting XML.
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.
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.
A number of chosen-ciphertext attacks against implementations of this specification have been published and demonstrated. They all involve the following elements:
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.
<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.
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:
<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.<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.
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]:
Accordingly, in situations where an attacker may be able to mount chosen-ciphertext attacks, we recommend the following to implementers:
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].
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.
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 it.
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.
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.
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.
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.
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.
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.
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'sQName
'sLocalPart
is'EncryptedData'
or 'EncryptedKey
' with an associated namespace name of 'http://www.w3.org/2001/04/xmlenc#'. Theapplication/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.
This section is non-normative.
Non-normative RELAX NG schema [RELAXNG-SCHEMA] information is available in a separate document [XMLSEC-RELAXNG].
This informative section outlines the definition and reserves identifiers for algorithms that have no requirements for implementation and have not been tested for interoperability.
This section is non-normative.
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.
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.