/*]]>*/
Copyright © 2010 W3C® (MIT, ERCIM, Keio), 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 arbitrary in a variety of
formats, including octet streams and other unstructured data, or
structure data (including an
formats such as XML document), documents,
an XML element, or XML element content. The result of encrypting
data is an XML Encryption element which 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 is a Working Draft of "XML Encryption
1.1." At the time of this publication, the most recent
W3C
Recommendation of XML Encryption 1 is the 10 December
2002 XML Encryption Recommendation . Please review differences between the previous and this
Working Draft , and differences between the previous XML
Encryption Recommendation and this Working Draft ; a detailed
explanation of changes is also
available.
Conformance-affecting changes against this previous
recommendation mainly affect the set of mandatory to implement
cryptographic algorithms, by adding Elliptic Curve Diffie-Hellman
Key Agreement. There is currently no consensus about the inclusion
of this algorithm as mandatory to implement, and the Working Group
seeks early community input into what
algorithms should be supported. Arguments for and against specific
approaches are called out in an editorial note in section 5.1 Algorithm Identifiers and Implementation
Requirements .
This document was developed
published by the XML Security Working Group
. The as
a Working Group expects
Draft. This document is intended to
advance this Working Draft become a W3C Recommendation. If you wish to Recommendation Status. Please send make comments about
regarding this document document, please
send them to public-xmlsec-comments@w3.org public-xmlsec@w3.org (with public archive (
subscribe ,archives ). All feedback
is welcome.
Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.
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 .
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 which 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 [ XML-schema 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", "
must ", "
must
not ", " required
", " shall ", " shall not ", " should ", " should not
", " recommended
", " may ", and "OPTIONAL"
" optional " in this specification are to be interpreted as
described in RFC2119 [ KEYWORDS RFC2119 ]:
"they MUST"They must only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)"
Consequently, we use these capitalized keywords to unambiguously
specify requirements over protocol and application features and
behavior that affect the interoperability and security of
implementations. These key words are not used (capitalized) to
describe XML grammar; schema definitions unambiguously describe
such requirements and we wish to reserve the prominence of these
terms for the natural language descriptions of protocols and
features. For instance, an XML attribute might be described as
being "optional." Compliance with the XML-namespace specification [
XML-NS XML-NAMES ] is described as "REQUIRED." "
required ."
The design philosophy and requirements of this specification
(including the limitations related to instance validity) are
addressed in the original XML Encryption
Requirements [ EncReq XML-ENCRYPTION-REQ ] and
the XML Security 1.1 Requirements document [ XMLSEC11-REQS ].
No provision is made for an explicit
version number in this syntax. If a future version is needed, it
will This specification makes use
a different namespace. The experimental
of XML namespace namespaces, and
uses Uniform Resource Identifiers [ XML-NS URI ] URI that MUST be used by implementations
to identify resources, algorithms, and
semantics.
Implementations of this (dated) specification is: must use the following
XML namespace URIs:
URI | namespace |
XML |
---|---|---|
|
default namespace |
<!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. For example "
The present version does not coin any new
elements or algorithm identifiers in that namespace; instead,
the &xenc;Element"
http://www.w3.org/2009/xmlenc11#corresponds to
"http://www.w3.org/2001/04/xmlenc#Element". ( xenc11:
) namespace is used.
This No
provision is made for an explicit version number in this syntax. If
a future version of this specification makes use requires explicit
versioning of the XML Signature [
XML-DSIG ] document format, a
different namespace and schema
definitions will be used.
URIs [ URI ] MUST abide by the [
XML-Schema ] anyURI type definition Additionally, this specification uses elements and
algorithm identifiers from the
XML Signature name spaces [ XML-DSIG , 4.3.3.1 The URI Attribute XMLDSIG-CORE1 ]
specification (i.e., permitted characters, character escaping,
scheme support, etc.). ]:
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 Working Group members to this
specification are gratefully acknowledged in accordance with the
contributor
policies and the active WG roster
. : Joseph Ashwood Ashwood, Simon
Blake-Wilson, Certicom Certicom, Frank D. Cavallito, BEA Systems Systems, Eric
Cohen, PricewaterhouseCoopers
PricewaterhouseCoopers, Blair Dillaway,
Microsoft (Author) (Author), Blake Dournaee, RSA Security Security,
Donald Eastlake, Motorola (Editor)
(Editor), Barb Fox, Microsoft Microsoft,
Christian Geuer-Pollmann, University of Siegen Siegen, Tom
Gindin, IBM IBM, Jiandong Guo, Phaos Phaos, Phillip
Hallam-Baker, Verisign Verisign, Amir Herzberg, NewGenPay NewGenPay,
Merlin Hughes, Baltimore Baltimore, Frederick Hirsch Hirsch, Maryann
Hondo, IBM IBM, Takeshi Imamura, IBM (Author) (Author),
Mike Just, Entrust, Inc. Inc., Brian LaMacchia, Microsoft Microsoft,
Hiroshi Maruyama, IBM IBM, John Messing, Law-on-Line Law-on-Line, Shivaram Mysore, Sun Microsystems Microsystems, Thane Plambeck, Verisign Verisign,
Joseph Reagle, W3C (Chair, Editor) Editor),
Aleksey Sanin Sanin, Jim Schaad, Soaring Hawk Consulting Consulting,
Ed Simon, XMLsec (Author) (Author), Daniel Toth, Ford Ford, Yongge
Wang, Certicom Certicom, Steve Wiley, myProof myProof.
Additionally, we thank the following for their comments during
and subsequent to Last Call: Martin Dürst, Dürst,
W3C , Dan
Lanz, Zolera Zolera, Susan Lesch, W3C , David Orchard, BEA
Systems Systems, Ronald Rivest, MIT .
Contributions for version 1.1 were received from the members of
the XML Security Working Group: TBD. See
public list of participants for now. 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.
This section is non-normative.
This section provides an overview and examples of XML Encryption syntax. The formal syntax is found in Encryption Syntax (section 3); 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?>?<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
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.
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 is 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>
Or, 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></a> </a></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></a> </ EncryptedDat a></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>EncryptedData</CipherValue><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>new
EncryptedData</CipherValue></a> </a> </ pay:PaymentInf o></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
)[s1] <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.w3.org/2001/04/xmlenc#Element'/> [s2] <EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#tripledes-cbc'/> [s3] <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'>[s4] <ds:KeyName>John Smith</e>[s4] <ds:KeyName>John Smith</ds:KeyName> [s5] </ds:KeyInfo> [s6] <CipherData><CipherValue>DEADBEEF</CipherValue></CipherData> [s7] </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] <d xmlns:ds='http://www.w3.org/2000/09/xmldsig#'> [t04] <ds: URI='#EK'[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:KeyNam
e>
[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 must be implemented unless
otherwise noted. The syntax is defined via [ XML-Schema XMLSCHEMA-1
], [ XMLSCHEMA-2 ] with the following XML preamble,
declaration, internal entity, and import:
Schema Definition: <?xml version="1.0" encoding="utf-8"?>(Note a newline has been added to schemaLocation to fit on the page.)<!DOCTYPE schema PUBLIC "-//W3C//DTD XMLSchema 200102//EN"<!DOCTYPE schema PUBLIC "-//W3C//DTD XMLSchema 200102//EN" "http://www.w3.org/2001/XMLSchema.dtd" [ <!ATTLIST schemaxmlns:xenc CDATA #FIXED 'http://www.w3.org/2001/04/xmlenc#'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#'element='qualified'>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" "http://www.w3.org/2001/XMLSchema.dtd" [ <!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'/>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. Implementation MUST must generate laxly schema valid [
XML-schema XMLSCHEMA-1 ], [
XMLSCHEMA-2 ]
EncryptedData
or EncryptedKey
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 should create these XML
structures ( EncryptedType
elements and their
descendants/content) in Normalization Form C [ NFC ,
NFC-Corrigendum ].
Schema Definition:<complexType name='' abstract='true'><complexType name='EncryptedType' abstract='true'> <sequence><element name=''<element name='EncryptionMethod' type='xenc:EncryptionMethodType' minOccurs='0'/><element ref='' minOccurs='0'/> <element ref=''/><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 [
XML-DSIG 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
mandatory processing described in
Processing
Rules: Decryption (section 4.2). 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 [
MIME 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.
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 by 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.4.2) uses the ds:DigestMethod
and
OAEPparams
elements. (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
which is not permitted by the
algorithm or the presence of a KeySize
child
inconsistent with the algorithm MUST
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 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=''/> <complexType name=''><element name='CipherData' type='xenc:CipherDataType'/> <complexType name='CipherDataType'> <choice><element name='' type='base64Binary'/> <element ref=''/><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 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 similar to that of defined
in XML Signature [ XML-DSIG
XMLDSIG-CORE1
]. However, there ], however XML Encryption places the
Transforms
element in the XML Encryption namespace since it
is a difference between signature and
encryption processing. used in XML
Encryption to obtain an octet stream for decryption. In [
XML-DSIG 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:rep="http://www.example.org/repository"> self::text()[parent::rep:CipherValue[@Id="example1"]] </ds:XPath> </ds:Transform> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#base64"/> </Transforms> </CipherReference>
Implementations MUST must
support the CipherReference
feature and the same URI
encoding, dereferencing, scheme, and HTTP response codes as that of
[ XML-DSIG XMLDSIG-CORE1 ]. The Transform
feature and particular transform algorithms are OPTIONAL. optional .
Schema Definition:<element name=''/> <complexType name=''><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 serves as the new document root.
Schema Definition:<element name=''/> <complexType name=''><element name='EncryptedData' type='xenc:EncryptedDataType'/> <complexType name='EncryptedDataType'> <complexContent><extension base=''><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 [ ds:KeyValue
is ds:KeyName
to refer to an
EncryptedKey
CarriedKeyName
is
ds:RetrievalMethod
is
In addition, we provide two additional child elements:
applications MUST must support
EncryptedKey
(section
3.5.1) and MAY may support
AgreementMethod
(section 5.5).
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).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=''/> <complexType name=''><element name='EncryptedKey' type='xenc:EncryptedKeyType'/> <complexType name='EncryptedKeyType'> <complexContent><extension base=''><extension base='xenc:EncryptedType'> <sequence><element ref='' minOccurs='0'/> <element name='' type='string' minOccurs='0'/><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 is to
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 is to 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
[
with a XML-DSIG XMLDSIG-CORE1
]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
with this type 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.
Schema Definition: <!-- <attribute name='Type' type='anyURI' use='optional'fixed='http://www.w3.org/2001/04/xmlenc#' />fixed='http://www.w3.org/2001/04/xmlenc#EncryptedKey' /> -->
ReferenceList
ElementReferenceList
is an element that contains pointers
from a key value of an EncryptedKey
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=''><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
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
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 Decyptor will, conversely, replae 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 break schemas 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 commonly perform type-specific processing. 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
(elements derived from EncryptedType ),
element, the encryptor
must: must :
ds:KeyInfo
as
appropriate (e.g., ds:KeyName
,
ds:KeyValue
, ds:RetrievalMethod
,
etc.)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.DerivedKey
element with associated child elements. The
result may, as in the EncryptedKey
ds:KeyInfo
, or it may exist elsewhere.Encrypt the octets using the algorithm and key from steps 1 and 2. key.
Unless the decryptor will implicitly know the
type of the encrypted data, the encryptor
SHOULD provide should set the type for
representation. The definition of this type as bound to an
identifier specifies how Type
to obtain and
interpret the plaintext octets after decryption. For example, the
identifier could indicate that
the data is an instance intended interpretation of another application (e.g., some XML compression
application) that must be further processed. Or, if
the cleartext data. See Well-Known Type
parameter values for known
parameter values.
If the data is a simple octet
sequence it MAY 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
").
EncryptedType (
EncryptedData
or EncryptedKey
An
or EncryptedType EncryptedDataEncryptedKey
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 EncryptedType , EncryptedData
or EncryptedKey
element, then the base64
representation of the encrypted octet sequence is CipherValue
element.EncryptedType EncryptedData
EncryptedKey
element, then the URI and transforms (if any)
required for the CipherReference
element.For each
or
EncryptedType derived
element, (i.e., EncryptedDataEncryptedKey
), to be
decrypted, the decryptor must: must :
ds:KeyInfo
CipherData
element.
CipherValue
child element is present, then
the associated text value is retrieved and base64 decoded so as to
obtain the encrypted octet sequence.CipherReference
child element is present, the
URI and transforms (if any) are used to retrieve the encrypted
octet sequence.Encryption and decryption operations are transforms 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 [
XML-DSIG XMLDSIG-CORE1 ] validation or an XSLT
transform) the encrypting application must be careful to preserve
information necessary for that process's success.
For interoperability purposes, the
following types MUST be implemented such that an implementation
will be able to take as input and yield as output data matching the
production rules 39 and 43 from [ XML ]: element '
http://www.w3.org/2001/04/xmlenc#Element ' "[39] element ::=
EmptyElemTag | STag content ETag " content '
http://www.w3.org/2001/04/xmlenc#Content ' "[43] content ::=
CharData ? (( element | Reference | CDSect | PI | Comment )
CharData ?)*" The following sections contain specifications
for decrypting, replacing, and serializing XML content (i.e.,
Type
' element
' or element ' content
') using the [ XPath XPATH ] data model. These sections are
non-normative and OPTIONAL optional to implementers of this
specification, but they may be normatively referenced by and
MANDATORY to other specifications that require a consistent
processing for applications, such as [ XML-DSIG-Decrypt 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 the Decryption Processing (section 4.2). Y is node-set representing the decrypted content obtained by the following steps:
Where X is the [ XPath
XPATH ] node set corresponding to an XML
document and e is an EncryptedData
element
node in X .
EncryptedData
element type. In which case:
In Encrypting XML (section 4.1, step
3.1), when serializing an XML fragment special care SHOULD 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 of a A Decrypt Implementation (section 4.3.1)),
then it may affect the interpretation of the serialized data.
To solve this problem, a canonicalization algorithm MAY may be augmented as follows for use as an XML
encryption serializer:
xmlns=""
) 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 [ XML-Signature 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
XML-EXC-C14N ].
For example, if the element:
<Bongo href="example.xml"/>
is taken from a context and serialized with no
xml:base
[ 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 can not
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 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 [
XML 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 XML-INFOSET
] of an external entity.
The process consists of the following steps:
dummy
element start-tag with namespace
declaration attributes declaring all the namespaces in the parsing
context.dummy
element end-tag.In the above steps, the document type declaration and
dummy
element tags MUST
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 fed 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 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" " required " or
"OPTIONAL", " optional ", refer
to implementation, not use. Furthermore, the mechanism is
extensible, and alternative algorithms may be used.
There is currently no consensus on mandatory to implement algorithms; the current draft text represents one possible outcome. Positions of some Working Group members against the currently expressed set of mandatory to implement algorithms include:
The opposing position is that, going forward, this specification needs to have credible algorithm agility for both hash and public-key algorithms: Should one set of algorithms prove weak, this would enable a quick switch-over. Therefore, there should be two mandatory to implement public-key algorithms from different families. At this time, elliptic curve based algorithms are the only credible contenders. They have the additional benefit of providing a reasonable balance between key sizes and security level.
The table below lists the categories of algorithms. Within each category, a brief name, the level of implementation requirement, and an identifying URI are given for each algorithm.
Block encryption 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
.
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
.
ANSI X9.52 [ TRIPLEDES ] 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"/>
[ 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"/>
AES-GCM [ SP800-38D ]is an authenticated encryption mechanism. It is equivalent to doing these two operations in one step - HMAC signing followed by AES-CBC encryption.
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 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 [ SP 800-56A
SP800-56A ] (and
equivalent to the KDF3 function defined in ANSI X9.44-2007 [
X9.44 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 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.
optional .
The AlgorithmID
, PartyUInfo
,
PartyVInfo
, SuppPubInfo
and
SuppPrivInfo
attributes are as defined in NIST [ SP800-56A
. ].
Their presence is optional but AlgorithmID
,
PartyVInfo
and PartyUInfo
MUST must be present for applications that need to
comply with NIST [ SP800-56A .
].
In [ NIST SP800-56A ] does not
define particular values for the AlgorithmID subfield but for the
purposes of this specification, the ], AlgorithmID
, PartyUInfo
,PartyVInfo
,SuppPubInfo
attribute
SHALL have the value and
"00" SuppPrivInfo(i.e.
one byte long) when the derived key is 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 with the TRIPLEDES
or the AES-128 encryption or key wrap algorithms. This value also
indicates that the key constitutes the complete KDF output.
when encoding bitstring values for The
,PartyUIInfo AlgorithmIDPartyUInfo
,PartyVInfo
,SuppPubInfo
attribute
shall, when present, contain information identifying
and SuppPrivInfo
:
Example: the value " bitstring
,which is
00 " when the sender 11011identified with an X.509 certificate. Other
values of 5 bits long, gets 3
additional padding bits to become the initial substring may be defined bitstring 11011000
(or
D8
in later revisions of this specification. When identifying
the sender hex). This bitstring is then
prepended with an X.509
certificate, one octet
identifying the subsequent substring
shall use number of padding bits to
become the "variable-length" encoding
defined in Section 5.8.1 octet string
(in hex) 03D8
,which then finally is encoded as a hexBinary
string value of "03D8".
Note that as specified in [
NIST SP800-56A ] and shall contain (the hex encoding of) the length of
the certificate in big-endian representation immediately followed
by the (hex encoding) of the DER-encoded certificate. The length
field ], these attributes shall
always be two
octets (i.e. 4 hex digits) long. The PartyVIInfo attribute shall,
when present, contain information identifying the intended
recipient of data encrypted (or authenticated) concatenated to form a bit string “OtherInfo” that is
used with the derived key.
key derivation function. The
encoding of the attribute value
concatenation shall be as defined for PartyUIInfo , but done using information
identifying the recipient.
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 is:
given below. In this example, the bitstring
value of AlgorithmID
is 00000000
and the
bitstring value of PartyUInfo
is
11011
:
<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="00" PartyUInfo="" PartyVInfo=""><xenc11:ConcatKDFParams AlgorithmID="0000" PartyUInfo="03D8" PartyVInfo=""> <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 is and the ASN.1 type
definitions for its parameters are defined in PKCS #5
v2.0 [ PKCS5 ]
and an ]. The XML schema
definitions for its the parameters is
defined in PKCS #5 v2.0 Amd. 1 [
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" minOccurs="0"/> </sequence> <attribute name="Algorithm"/> </complexType> <complexType name="PRFAlgorithmIdentifierType"> <complexContent> <restriction base="xenc11:AlgorithmIdentifierType"> <attribute name="Algorithm" type="anyURI" default="http://www.w3.org/2000/09/xmldsig#hmac-sha1"/> </restriction> </complexContent> </complexType>
The
element
pkcs-5:PBKDF2-params
PBKDF2-paramstype defined in and its child elements have the latter document shall be used same names and meaning as a
child the corresponding
components of the
xenc11:KeyDerivationMethod
PBKDF2-paramswhen using this key derivation algorithm. Also,
ASN.1 type in [ PKCS5 ].
The AlgorithmIdentifierType
corresponds to the Algorithm AlgorithmIdentifierattribute type of
[ PKCS5 ] and carries the algorithm identifier in the
pkcs-5:PRF Algorithmelement
SHALL attribute. Algorithm specific
parameters, where applicable, can be present. 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 for PBKDF2 and the default
PRF algorithm (HMAC-SHA1) is the same as in [ PKCS5 ]. It is
RECOMMENDED recommended to use
HMAC-SHA256 as the PRF algorithm (see [ XML-DSIG 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#" xmlns:pkcs-5="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5v2-0#"> <xenc11:KeyDerivationMethod Algorithm="http://www.rsasecurity.com/rsalabs/pkcs/schemas/pkcs-5#pbkdf2"> <pkcs-5:PBKDF2-params> <Salt> <Specified>Df3dRAhjGh8=</Specified> </Salt> <IterationCount>2000</IterationCount> <KeyLength>16</KeyLength> <PRF Algorithm="http://www.w3.org/2001/04/xmldsig-more#hmac-sha256"/> </pkcs-5:PBKDF2-params> </xenc11:KeyDerivationMethod> <xenc:ReferenceList> <xenc:DataReference URI="#ED"/> </xenc:ReferenceList> <xenc11:MasterKeyName>Our shared secret</xenc11:MasterKeyName>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 RSA v1.5 Key Transport algorithm given below are those used in conjunction with TRIPLEDES and the Cryptographic Message Syntax (CMS) of S/MIME [ CMS-Algorithms ]. The RSA v2 Key Transport algorithm given below is that used in conjunction with AES and CMS [ AES-WRAP ].
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 [ MIME 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], 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. Support of this key transport
algorithm for transporting 192 bit keys is MANDATORY to implement.
Support of this algorithm for transporting other keys is
OPTIONAL. optional . RSA-OAEP is
RECOMMENDED recommended for the
transport of AES keys.
The resulting base64 [ MIME
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>
The RSAES-OAEP-ENCRYPT algorithm, as specified in RFC 3447 [
PKCS1 ],
takes three parameters. The two user specified parameters are a
MANDATORY message digest function and an OPTIONAL optional encoding octet
string OAEPparams
. The message digest function is
indicated by the Algorithm
attribute of a child
ds:DigestMethod
element and the mask generation
function, the third parameter, is always MGF1 with SHA1
(mgf1SHA1Identifier). Both the message digest and mask generation
functions are used in the EME-OAEP-ENCODE operation as part of
RSAES-OAEP-ENCRYPT. The encoding octet string is the base64
decoding of the content of an optional OAEPparams
child element . If no OAEPparams
child is provided, a
null string is used.
Schema Definition: <!-- use these element types as children of EncryptionMethod when used with RSA-OAEP --> <element name='OAEPparams' minOccurs='0' type='base64Binary'/> <element ref='ds:DigestMethod' minOccurs='0'/>
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>
The CipherValue
for an RSA-OAEP encrypted key is
the base64 [ MIME RFC2045 ] encoding of the octet string
computed as per RFC 3447 [ PKCS1 ,
], section 7.1.1: Encryption
operation]. operation. As described in the EME-OAEP-ENCODE
function RFC 3447 [ PKCS1 , ], section 7.1.1],
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 the mask generator
function 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 must implement RSA-OAEP for the transport of
128 and 256 bit keys. They MAY
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 on-line 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 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><xenc: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"/><xenc: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: <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 must be
maintained in ZZ
so it will be the same length, in
bytes, as p
. The size of p
MUST 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. optional . However, if
implemented, such implementations MUST
must support the Legacy Key Derviation
Function and SHOULD 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 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 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 ECPublicKey element [ XML-DSIG XMLDSIG-CORE1
]. Note that if the curve parameters are explicitly stated using
the ECParameters element, then the Cofactor element MUST 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 section 5.7.1.2 of NIST SP 800-56A [ SP800-56A ]. 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 required to support
ECDH-ES key agreement using the P-256 prime curve specified in
Section D.2.3 of FIPS 186-3 [ FIPS186-3
FIPS-186-3 ].
(This is the same curve that is REQUIRED required in XML
Signature 1.1 to be supported for the ECDSAwithSHA256 algorithm.)
It is further RECOMMENDED 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 must implement ConcatKDF
(see Section 5.4.1 ). 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:ECPublicKey> <!-- ephemeral ECC public key of the originator --> </dsig11:ECPublicKey> </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
must support TRIPLEDES wrapping of 168 bit
keys as described in [ CMS-Wrap
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 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.
These identifiers are used 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 [ DRAFT-HOUSLEY-KW-PAD 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.
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 [
XML-DSIG 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 required in this
specification only for backwards-compatibility reasons.
The SHA-1 algorithm [ SHA 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 [ SHA
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 [ SHA
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 [ SHA
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 [ Canon 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 [ Exclusive 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.
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 [ EncReq 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:
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:
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.
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.
An implementation is conformant to this specification if it
successfully generates syntax according to the schema definitions
and satisfies all MUST/REQUIRED/SHALL
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 [ XML-Encryption XMLENC-CORE1 ] 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 ]
MIME media type name: application
MIME 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 [XML-EncryptionXMLENC-CORE ] Security Considerations section.
Interoperability considerations: none
Published specification: [ XML-Encryption XMLENC-CORE
]
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, they 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 nameMUSTmust 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 [XML-schemaXMLSCHEMA-1 ], [ XMLSCHEMA-2 ].File extension(s): .xml
Macintosh File Type Code(s): "TEXT"
Person & email address to contact for further information:
Joseph Reagle <reagle@w3.org>
XENC Working Group <xml-encryption@w3.org>
Intended usage: COMMON
Author/Change controller:
The XML Encryption specification is a work product of the World
Wide Web Consortium (W3C) ( 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 ].
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.