Copyright ©2001 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use and software licensing rules apply.
This document specifies a process for encrypting data and representing the result in XML. The data may be arbitrary 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.
This is Last Call for the "XML Encryption Syntax and Processing" specification from the XML Encryption Working Group (Activity). This version specifies the Working Group's apprach to satisfying the requirements stemming from the March 2001 face-to-face meeting and subsequent discussion on the list. The last call period is 3 weeks, ending on 9 November 2001.
The Working Group will try to use a new namespace when changes in its syntax or processing are substantive. However, this namespace might be reused (prior to reaching Candidate Recommendation) by subsequent drafts in such a way as to cause instances using the namespace to become invalid or to change in meaning or affect the operation of existing software. Requests for a more stringent level of namespace stability should be made to the Working Group.
Publication of this document 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 a W3C Working Draft as anything other than a "work in progress." A list of current W3C working drafts can be found at http://www.w3.org/TR/.
Please send comments to the editors (<[email protected]>, <[email protected]>) and cc: the list [email protected] (archives)
Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page in conformance with W3C 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] to describe the content model.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this specification are to be interpreted as described in RFC2119 [KEYWORDS]:
"they MUST only be used where it is actually required for interoperation or to limit behavior which has potential for causing harm (e.g., limiting retransmissions)"
Consequently, we use these capitalized keywords to unambiguously specify requirements over protocol and application features and behavior that affect the interoperability and security of implementations. These key words are not used (capitalized) to describe XML grammar; schema definitions unambiguously describe such requirements and we wish to reserve the prominence of these terms for the natural language descriptions of protocols and features. For instance, an XML attribute might be described as being "optional." Compliance with the XML-namespace specification [XML-NS] is described as "REQUIRED."
The design philosophy and requirements of this specification are addressed in the XML Encryption Requirements document [EncReq].
No provision is made for an explicit version number in this syntax. If a future version is needed, it will use a different namespace. The experimental XML namespace [XML-NS] URI that MUST be used by implementations of this (dated) specification is:
xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'
Additionally, this specification makes use of the XML Signature [XML-DSIG] namespace and schema definitions
xmlns:ds='http://www.w3.org/2000/09/xmldsig#'
This namespace is also used as the prefix for algorithm
identifiers used by this specification. While applications MUST
support XML and XML namespaces, the use of internal
entities [XML] or our
&xenc;
entity or "xenc
" XML namespace
prefix and defaulting/scoping conventions are OPTIONAL; we use
these facilities to provide compact and readable examples.
The contributions of the following working group members to this specification are gratefully acknowledged in accordance with the contributor policies and the active WG roster.
This section provides an overview and examples of XML Encryption syntax. The formal syntax is found in Core Encryption Syntax (section 3); the specific processing is given in Processing Rules (section 4).
Expressed in shorthand form, the EncryptedData
element has the
following structure:
<EncryptedData Id? Type?> <EncryptionMethod/>? <ds:KeyInfo> <EncryptedKey>? <AgreementMethod>? <ds:KeyName>? <ds:RetrivalMethod>? <ds:*>? </ds:KeyInfo>? <CipherData> <CipherValue>? <CipherReference URI?>? </CipherData> </EncryptedData>
The CipherData
element envelopes or references the
raw encrypted data. 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>Bank of the Internet</Issuer> <Expiration>04/02</Expiration> </CreditCar
d> </PaymentInf
o>
This markup represents that John Smith's 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> </CipherDat
a> </EncryptedDat
a> </PaymentInf
o>
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> </CipherDat
a> </EncryptedDat
a> </CreditCar
d> </PaymentInf
o>
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> </CipherDat
a> </EncryptedDat
a> </Number> <Issuer>Bank of the Internet</Issuer> <Expiration>04/02</Expiration> </CreditCar
d> </PaymentInf
o>
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 set. This applies to arbitrary data including XML documents.
<?xml version='1.0'?> <EncryptedData xmlns='http://www.w3.org/2001/04/xmlenc#' Type='http://www.isi.edu/in-notes/iana/assignments/media-types/text/xml'> <CipherData> <CipherValue>A23B45C56</CipherValue> </CipherDat
a> </EncryptedDat
a>
An XML document may contain zero or more
EncryptedData
elements. However,
EncryptedData
can not 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>original
EncryptedData</CipherValue> </CipherDat
a> </EncryptedDat
a> </pay:PaymentInf
o>
A valid super-encryption of
'
//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> </CipherDat
a> </EncryptedDat
a> </pay:PaymentInf
o>
where '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#3des-cbc '/> [s3] <ds:KeyInfo xmlns:ds='http://www.w3.org/2000/09/xmldsig#'> [s4] <ds:KeyName
> John Smith </ds:KeyNam
e> [s5] </ds:KeyInf
o> [s6] <CipherData><CipherValue>DEADBEEF</CipherValue></CipherDat
a> [s7] </EncryptedDat
a>
[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 an
external octet sequence that is identified by a media type URI.
[s2]
This (3DES CBC) is a symmetric key cipher.
[s4-s5]
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:xenc='http://www.w3.org/2001/04/xmlenc#'> [t02] <EncryptionMethod Algorithm='http://www.w3.org/2001/04/xmlenc#aes128-cbc'/> [t03] <ds:KeyInfo
xmlns:ds='http://www.w3.org/2000/09/xmldsig#'> [t04] <ds:RetrievalMethod
URI='#EK' Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"> [t05] <ds:KeyNam
e>John Doe<ds:KeyNam
e> [t06] </ds:KeyInf
o> [t07] <CipherData><CipherValue>DEADBEEF</CipherValue></CipherDat
a> [t08] </EncryptedDat
a>
[t02]
This (AES-128-CBC) is a symmetric key
cipher.
[t03]
The (AES) key is located at '#EK'.
[t04]
ds:RetrievalMethod
is used to
indicate the location of a key with type
&xenc;EncryptedKey.
[t05]
ds:KeyName
provides an
alternative method of identifying the key needed to decrypt the
CipherData
. Either or both the KeyName
and KeyRetrivalMethod
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'CarriedKeyName
="John Doe" [t10] xmlns='http://www.w3.org/2001/04/xmlenc#'> [t11] <EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/> [t12] <ds:KeyInfo
xmlns:ds='http://www.w3.org/2000/09/xmldsig#'> [t13] <ds:KeyNam
e>John Smith</ds:KeyNam
e> [t14] </ds:KeyInf
o> [t15] <CipherData><CipherValue>xyzabc</CipherValue></CipherDat
a> [t16] <ReferenceList> [t17] <DataReference URI='#ED'/> [t18] </ReferenceLis
t> [t19] </EncryptedKe
y>
[t09]
The EncryptedKey
element is
similar to the EncryptedData
element except that the
data encrypted is always a key value. The
CarriedKeyName
attribute is used to identify the
encrypted key value which may be referenced by the
KeyName
element in ds:KeyInfo
.
[t11]
The EncryptionMethod
is the RSA
public key algorithm.
[t13]
ds:KeyName
of "John Smith" is a
property of the key necessary for decrypting (using RSA) the
CipherData
.
[t15]
The CipherData
's
CipherValue
is an octet sequence that is encoded
(e.g., padded) by a referring encrypted object's
EncryptionMethod
. (Note, an EncryptedKey's
EncryptionMethod
is the algorithm used to encrypt
these octets and does not speak about what type of octets they
are.)
[t16-18]
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.
This section provides a detailed description of the syntax and features for XML Encryption. Features described in this section are mandatory to implement unless otherwise noted. The syntax is defined via [XML-Schema] with the following XML preamble, declaration, internal entity, and import:
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#'>
<!ENTITY % p ''>
<!ENTITY % s ''>
]>
<schema xmlns='http://www.w3.org/2001/XMLSchema' version='0.1'
xmlns:ds='http://www.w3.org/2000/09/xmldsig#'
xmlns:xenc='http://www.w3.org/2001/04/xmlenc#'
targetNamespace='http://www.w3.org/2001/04/xmlenc#'
elementFormDefault
='qualified'>
<import namespace='http://www.w3.org/2000/09/xmldsig#'
schemaLocation='http://www.w3.org/TR/2001/CR-xmldsig-core-20010419/xmldsig-core-schema.xsd'/>
EncryptedType
EncryptedType
is the abstract type from which
EncryptedData
and EncryptedKey
are
derived. While these two latter element types are very similar with
respect to their content models, a syntactical distinction is
useful to processing.
Schema Definition: <complexType name='EncryptedType
' abstract='true'> <sequence> <element name='EncryptionMethod
' type='xenc:EncryptionMethodType
' minOccurs='0'/> <element ref='ds:KeyInfo
' minOccurs='0'/> <element ref='xenc:CipherData
'/> <element ref='xenc:EncryptionProperties'/> </sequence> <attribute name='Id' type='ID' use='optional'/> <attribute name='Type' 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 is assumed to be
known by the recipient.
ds:KeyInfo
is an optional element, defined by [XML-DSIG], that carries information about
the key used to encrypt the CipherData
. The new
elements defined by this specification that may appear as children
of ds:KeyInfo
are described in subsequent
sections.
CipherData
is a mandatory element that contains the
CipherValue
or CipherReference
with the
encrypted data.
Id
is an optional attribute providing for the
standard method of assigning a string id to the element within the
document context.
Type
is an optional attribute identifying type
information about the decrypted content. While optional, this
specification takes advantage of it for mandatory processing
described in Section 4.2. If the EncryptedData
element
contains data of Type
Element
or
ElementContent
, and replaces that data in an XML
Document context, 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
clear-text form.
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.
The optional Nonce
attribute
specifies
the presence and length of a nonce value that is prepended to the
CipherValue
or data identified by the
CipherReference
. A nonce is a value (used only once)
that is combined with the plaintext being encrypted in order to
increase its entropy; this prevents "dictionary attacks" that
encrypt "some known plaintext phrase with all possible keys so that
the key for any given encrypted message containing that phrase may
be obtained by lookup." [RFC2828]. Given that data is often
redundant (e.g., XML) and that attackers may know the data's
structure, applications are RECOMMENDED to encrypt data with high
entropy, either by its own nature or by use of the
Nonce
attribute.
Schema Definition: <element name='CipherData
' type='xenc:CipherDataType
'/> <complexType name='CipherDataType
'> <choice> <element name='CipherValue
' type='base64Binary'/> <element ref='xenc:CipherReference
'/> </choice> <attribute name="Nonce" type="base64Binary" use="optional"/> </complexType>
CipherReference
ElementIf CipherValue
is not supplied directly, the
CipherReference
identifies a source which, when
processed, yields the encrypted octet sequence.
The actual value is obtained as follows. The
CipherReference
URI
contains an
identifier that is dereferenced. Should the
CipherReference
element contain an OPTIONAL sequence
of Transforms
, the data resulting from dereferencing
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 Transform
s
is similar to that of [XML-DSIG] reference validation. However, there is a
difference between signature and encryption processing. In [XML-DSIG] 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::CipherValue[@id="example1"]] </ds:XPath> <ds:Transform> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#base64"/> </Transforms> </CipherReference>
Transforms
is in the xenc namespace because the
sequence of transforms
Schema Definition: <element name='CipherReference
' type='xenc:CipherReferenceType
'/> <complexType name='CipherReferenceType
'> <sequence> <element name='Transforms' type='xenc:TransformsType' minOccurs='0'/> </sequence> <attribute name='URI' type='anyURI' use='required'/> </complexType> <complexType name="TransformsType"> <sequence> <element ref="ds:Transform" maxOccurs="unbounded"/> </sequence> </complexType>
EncryptedData
elementThe EncryptedData
element is the core element in
the syntax. Not only does its CipherData
child contain
the encrypted data, but it's also the element that replaces the
encrypted element, or serves as the new document root.
Schema Definition: <element name='EncryptedData
' type='xenc:EncryptedDataType
'/> <complexType name='EncryptedDataType
'> <complexContent> <extension base='xenc:EncryptedType
'> </extension> </complexContent> </complexType>
ds:KeyInfo
ElementThere are three ways that the keying material needed to decrypt
CipherData
can be provided:
EncryptedData
or EncryptedKey
element specify the associated keying material via a child of
ds:KeyInfo
. All of the child elements of
ds:KeyInfo
specified in [XML-DSIG] MAY be used as qualified:
ds:KeyValue
to
transport the encryption key is obviously NOT RECOMMENDED.KeyName
to refer to an
EncryptedKey
CarriedKeyName
is
RECOMMENDED.ds:RetrievalMethod
is
REQUIRED.In addition, we provide two additional child elements:
applications MUST support EncryptedKey
(Section 3.4.1)
and MAY support AgreementMethod
(Section
5.5).
KeyInfo
)
EncryptedKey
element can specify the
EncryptedData
or EncryptedKey
to which
its decrypted key will apply via a DataReference
or KeyReference
(Section
3.5).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).
Schema Definition: <element name='EncryptedKey
' type='xenc:EncryptedKeyType
'/> <complexType name='EncryptedKeyType
'> <complexContent> <extension base='xenc:EncryptedType
'> <sequence> <element ref='xenc:ReferenceList
' minOccurs='0'/> </sequence> <attribute name='CarriedKeyName
' type='string' use='optional'/> <attribute name='Recipient' type='string' use='optional'/> </extension> </complexContent> </complexType>
ReferenceList
is an optional element containing
pointers to data and keys encrypted using this key. The reference
list may contain multiple references to EncryptedKey
and EncryptedData
elements. This is done using
KeyReference
and DataReference
elements
respectively. These are defined below.
CarriedKeyName
is an optional attribute for
associating a user readable name with the key value. This may then
be used to reference the key using the 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
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.
ds:RetrievalMethod
ElementThe ds:RetrievalMethod
[XML-DSIG]
with a Type
of 'http://www.w3.org/2001/04/xmlenc#EncryptedKey
'
provides a way to express a link to an EncryptedKey
element containing the key needed to decrypt the
CipherData
associated with an
EncryptedData
or EncryptedKey
element.
The ds:RetrievalMethod
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#EncryptedKey
' />
-->
ReferenceList
ElementReferenceList
is an element that contains pointers
from a key value to items encrypted by that key value
(EncryptedData
or EncryptedKey
elements).
Schema Definition: <element name='ReferenceList
'> <complexType> <sequence> <element name='DataReference
' type='xenc:ReferenceType
' minOccurs='0' maxOccurs='unbounded'/> <element name='KeyReference
' type='xenc:ReferenceType
' minOccurs='0' maxOccurs='unbounded'/> </sequence> </complexType> </element> <complexType name='ReferenceType
'> <sequence> <any namespace='##other' minOccurs='0' maxOccurs='unbounded'/> </sequence> <attribute name='URI' type='anyURI' use='required'/> </complexType>
DataReference
elements are used to refer to
EncryptedData
elements that were encrypted using the
key defined in the enclosing EncryptedKey
element.
Multiple DataReference
elements can occur if multiple
EncryptedData
elements exist that are encrypted by the
same key.
KeyReference
elements are used to refer to
EncryptedKey
objects that were encrypted using the key
defined in the enclosing EncryptedKey
element.
Multiple KeyReference
elements can occur if multiple
EncryptedKey
elements exist that are encrypted by the
same key.
For both types of references one may optionally specify child
elements to aid the recipient in retrieving the
EncryptedKey
and/or EncryptedData
elements. These could include information such as XPath transforms,
decompression transforms, or information on how to retrieve the
objects from a document storage facility. For example:
<ReferenceList> <DataReference><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:Transforms> </ds:Transform> </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 (i.e.,
date/time stamp or the serial number of cryptographic hardware used
during encryption).
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"/> </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:
For each data item to be encrypted as an
EncryptedData
or EncryptedKey
(elements
derived from EncryptedType
), the
encryptor must:
ds:KeyInfo
as
approriate (e.g., ds:KeyName
,
ds:KeyValue
, ds:KeyRetrievalMethod
,
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.EncryptedData
Type
attribute.EncryptedType
(EncryptedData
or EncryptedKey
)
structure:
An EncryptedType
structure represents all of the
information previously discussed including the encryption
algorithm, parameters, key, type of the encrypted data, etc.
CipherData
element within the
EncryptedData
, then the encrypted octet sequence is
base64 encoded and inserted as the content of a
CipherValue
element.EncryptedData
structure, then represent the URI,
and optional transforms, required for the Decryptor to retrieve the
encrypted octet sequence within a CipherReference
element.Type
of the encrypted data is Element
or Element
Content, then the encryptor MUST be able to
return the EncryptedData
element to the
application. The application MAY
use this as the top-level element in a new XML Document or insert
it into another XML document.
The encryptor SHOULD be able to replace the
unencrypted Element or Content with the EncryptedData element. When
an application requires an XML element or content
to be replaced, it supplies the XML Document context in addition to
identifying the element or content to be replaced. The
encryptor removes the identified element or
content and inserts the EncryptedData
element in its
place.
EncryptedData
element to the
application. The application MAY
use this as the top-level element in a new XML Document or insert
it into another XML document (which may require a
re-encoding).For each EncryptedType
derived element, (i.e.,
EncryptedData
or EncryptedKey
), to be
decrypted, the decryptor must:
ds:KeyInfo
element to be used. If some information is
omitted, the application MUST supply it.ds:KeyInfo
element, which may contain one or more
children elements. These children have no implied processing order.
If the data encryption key is encrypted, locate the corresponding
key to decrypt it. (This may be a recursive step as the
key-encryption key may itself be encrypted.) Or, one might retrieve
the data encryption key from a local store using the provided
attributes or implicit binding.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 optional transforms are used to retrieve the encrypted
octet sequence.EncryptedData
element(s). The
decryptor MUST support passing this key value to
the application for persistent storage. If it
represents encrypted data then processing as described below is
required.Type
and the UTF-8 encoded XML character data.EncryptedData
element with the decrypted
Element
or Element
Content represented by the UTF-8 encoded characters. The
decryptor is NOT REQUIRED to perform validation on
the serialized XML nor the result of this replacement operation.
The application supplies the XML Document context and identifies
the EncryptedData
element being replaced.Type
is unspecified
or is not Element
or Element
Content
Type
attribute value when
specified.Encryption and decryption operations are transforms on octets. As noted in the preceding discussion, the encrypting application is responsible for the serialization of XML into an octet sequence, and that octets' semantics, such that the decrypted data is useful to the decrypting application.
For example, if the applications 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, which will encoded in the optional
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 and after
decryption (e.g., XML Signature [XML-DSIG] 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.
EmptyElemTag
| STag
content
ETag"
[XML]
CharData
? ((element
| Reference
| CDSect
| PI
| Comment)
CharData
?)*" [XML]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 elements
representing the role of the algorithm, a reference to the formal
specification and definitions, where applicable, for the
representation of keys and the results of cryptographic
operations.
All algorithms listed below have implicit parameters depending on their role. For example, the data to be encrypted or decrypted, keying material, and direction of operation (encrypting or decrypting) for encryption algorithms. Any explicit additional parameters to an algorithm appear as content elements within the element. Such parameter child elements have descriptive element names, which are frequently algorithm specific, and SHOULD be in the same namespace as this XML Encryption specification, the XML Signature specification, or in an algorithm specific namespace. An example of such an explicit parameter could be a nonce (unique quantity) provided to a key agreement algorithm.
This specification defines a set of algorithms, their URIs, and requirements for implementation. Requirements are specified over implementation, not over requirements for encryption use. Furthermore, the mechanism is extensible, and alternative algorithms may be used.
The table below lists the categories of algorithms. Within each category, a brief name, the level of implementation requirement, and an identifying URI are given.
The schema for EncryptionMethod is as follows:
Schema Definition: <complexType name="EncryptionMethodType" mixed="true"> <sequence> <element name="KeySize" minOccurs="0" type="KeySizeType"/> <element name="DigestMethod" minOccurs="0" type="ds:DigestMethodType"/> <element name="OAEPparams" minOccurs="0" type="base64Binary"/> <any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> <!-- (0,unbounded) elements from (1,1) external namespace --> </sequence> <attribute name="Algorithm" type="anyURI" use="required"/> </complexType>
NOTE: Which child elements to the EncryptionMethod
algorithm role are allowed or required depends on the specific
value of the Algorithm
attribute URI; however, the
KeySize child element is always permitted. (Schema does not provide
a facility for expressing conditionality of child element
occurrence based on attribute value.) 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 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.)
Block encryption algorithms are designed for encrypting and
decrypting data. 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 the data 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.
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. (Each of these 64 bits of key contain 56 effective bits and 8 parity bits.) 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"/>
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 steam encryption algorithms are spercified herein but this section is included to provide general guidelines.
Stream algorithms typically use the optional
KeySize
explicit parameter. In cases where the key
size is not apparent from the algorithm URI or key source, as in
the use of key agreement methods, this parameter sets the key size.
If the size of the key to be used is apparent and disagrees with
the KeySize
parameter, an error MUST be returned.
Implementation of any stream algorithms is optional. The schema for
the KeySize parameter is as follows:
Schema Definition: <simpleType name='KeySizeType'> <restriction base="integer"/> </simpleType>
Key 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 KeyInfo
element. The type of key being
transported is given by the Algorithm
attribute of the
EncryptionMethod
child of the
EncryptedKey
parent of this KeyInfo
element. This attribute value must be the URI of an encryption
algorithm.
Key Transport algorithms may optionally be used to encrypt data
in which case the KeyInfo
of which they are a
grandchild is the child of an EncryptedData
element.
Because they use public key algorithms, Key Transport algorithms
are not efficient for the transport of any amounts of data
significantly larger than symmetric keys.
The Key Transport algorithms given below are those used in conjunction with the Cryptographic Message Syntax (CMS) of S/MIME [CMS-Algorithms, CMS-AES].
The RSAES-PKCS1-v1_5 algorithm, specified in RFC 2437 [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] encoding of the octet string
computed as per RFC 2437 [PKCS1, section
7.2.1: Encryption operation]. As specified in the EME-PKCS1-v1_5
function RFC 2437 [PKCS1, section
9.1.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 168 bits for TRIPLEDES and 128, 192, or 256 bits for AES. Support of this key transport algorithm for transporting 168 bit keys is mandatory to implement. Support of this algorithm for transporting other keys is optional. RAS-OAEP is recommended for the transport of AES keys.
The resulting base64 [MIME] string is
the value of the child text node of the CipherData
element, e.g.
<CipherData> IWijxQjUrcXBYoCei4QxjWo9Kg8D3p9tlWoT4 t0/gyTE96639In0FZFY2/rvP+/bMJ01EArmKZsR5VW3rwoPxw= </CipherData>
THE RSAES-OAEP-ENCRYPT, as specified in RFC 2437 [PKCS1], algorithm takes as explicit
parameters a message digest function and an optional octet string
OAEPparams
. The message digest function is indicated
by the Algorithm
attribute of a child
DigestMethod
element and the octet string is the
base64 decoding of the content of an optional
OAEPparams
child element. An example of an RSA-OAEP
element is:
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-oaep-mgf1p"> <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/> <OAEPparams> 9lWu3Q== </OAEPparams> <EncryptionMethod>
The CipherData
for an RSA-OAEP encrypted key is the
base64 [MIME] encoding of the octet string
computed as per RFC 2437 [PKCS1, section
7.1.1: Encryption operation]. As described in the EME-OAEP-ENCODE
function RFC 2437 [PKCS1, section
9.1.1.1], the value input to the key transport function is
calculated use the message digest function and string specified in
the DigestMethod
and OAEPparams
elements
and using the mask generator function MGF1 specified in RFC 2437.
The desired output length for EME-OAEP-ENCODE is one byte shorter
than the RSA modulus.
The transported key size is 168 bits for TRIPLEDES and 128, 192, or 256 bits for AES. Implementations MUST implement RSA-OAEP for the transport of 128 and 256 bit keys. They MAY implement RSA-OAEP for the transport of other keys.
A Key Agreement algorithm provides for the agreement to a shared
secret quantity based on certain types of compatible public keys
from both the sender and the recipient. Information to determine
the key associated with the originator 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.
The AgreementMethod
element appears as the content
of a ds:KeyInfo
since, like other
ds:KeyInfo
children, it yields a key. This
ds:KeyInfo
is in turn a child of an
EncryptedData
or EncryptedKey
element.
The Algorithm
attribute and KeySize
child
of the EncryptionMethod
element under this
EncryptedData
or EncryptedKey
element are
implicit parameters to the key agreement computation. In cases
where this EncryptionMethod
algorithm URI is
insufficient to determine the key length, a KeySize
MUST have been included. In addition, the sender may place a
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/Algorithm" <KeySize>80</KeySize> </EncryptionMethod> <ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <AgreementMethod Algorithm="Example:Agreement/Algorithm"> <Nonce> Zm9v </Nonce> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"> <OriginatorKeyInfo> <KeyValue>...originator...</KeyValue> </OriginatorKeyInfo> <RecipientKeyInfo> <KeyValue>...recipient...</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="Nonce" minOccurs="0" type="base64Binary"/> <element name="DigestMethod" minOccurs="0" type="ds:DigestMethodType"> <element name="OriginatorKeyInfo" minOccurs="0" type="ds:KeyInfoType"> <element name="RecipientKeyInfo" minOccurs="0" type="ds:KeyInfoType"> <any namespace="##other" minOccurs="0" maxOccurs="unbounded"/> <!-- (0,unbounded) elements from (1,1) external namespace --> </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.
A DH public key consists of three quantities, a large Prime p, a
"Generator" g, and "Public" such that Public = g**x mod p. The
corresponding private key is x. Because a Prime 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>
<element name="Prime" type="ds:CryptoBinary" minOccurs="0"/>
<element name="Generator" type="ds:CryptoBinary" minOccurs="0"/>
<element name="Public" type="ds:CryptoBinary"/>
</sequence>
</complexType>
The Diffie-Hellman (DH) key agreement protocol [ESDH] involves the derivation of shared secret information based on compatible DH keys from the sender and recipient. Two DH public keys are compatible if they have the same prime and generator. If, for the second one, Y = g**y mod p, then the two parties can calculate the shared secret ZZ = ( g**(x*y) mod p ) even though each knows only their own private key and the other party's public key. Leading zero bytes MUST be maintained in ZZ so it will be the same length, in bytes, as p. We require that p 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].
Diffie-Hellman key agreement is optional to implement. An example of a DH AgreementMethod element is as follows:
<xenc:AgreementMethod xenc:Algorithm="http://www.w3.org/2001/04/xmlenc#dh" xmlns="http://www.w3.org/2000/09/xmldsig#"> <xenc:Nonce>Zm9v</Nonce> <DigestMethod Algorith="http://www.w3.org/2000/09/xmldsig#sha1"/> <xenc:OriginatorKeyInfo> <X509Data><X509Certificate> ... </X509Certificate></X509Data> </OriginatorKeyInfo> <xenc:RecipientKeyInfo><KeyValue> ... </KeyValue></RecipientKeyInfo> </xenc:AgreementMethod>
(Add example with real "bits"...)
Assume the Diffie-Hellman shared secret is the octet sequence ZZ. The shared keying material needed will then be calculated as follows:
Keying Material = KM(1) | KM(2) | ...
where "|" is byte stream concatenation and
KM(counter) = DigestAlg ( EncryptionAlg | ZZ | counter | Nonce | KeySize ).
DigestMethod
child of
AgreementMethod
.Algorithm
attribute of the
EncryptionMethod
child of the
EncryptedData
or EncryptedKey
grandparent
of AgreementMethod
.Nonce
child
of AgreementMethod
, if present. If the
Nonce
element is absent, it is null.For example, the initial (KM(1)) calculation for the example above where the binary 1 counter byte is represented as the two character UTF-8 sequence "01", would be calculated as follows:
SHA-256 (Example:Block/AlgorithmZZ01foo40 )
where ZZ is the binary shared secret octet sequence and "foo" is the b ase64 decoding of "Zm9v".
(Actual digest value and agreed key to be added...)
Each application of DigestAlg for successive values of Counter will produces 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 SHA1 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.
Symmetric Key Wrap algorithms are shared secret key encryption
algorithms especially specified for encrypting and decrypting
symmetric keys. Their identifiers appear as Algorithm
attributes to EncryptionMethod
elements that are
children of EncryptedKey
which is in turn a child of
KeyInfo
which is in turn a child of
EncryptedData
or another EncryptedKey
.
The type of the key being wrapped is indicated by the
Algorithm
attribute of EncryptionMethod
child of the parent of the KeyInfo
grandparent of the
EncryptionMethod
specifying the symmetric key wrap
algorithm.
Some key wrap algorithms make use of the Key Checksum defined in CMS [CMS-Algorithms]. This is used to provide an integrity check value for the key being wrapped. The algorithm is
XML Encryption implementations MUST support TRIPLEDES wrapping of 168 bit keys and may optionally support TRIPLEDES wrapping of other keys.
An example of a TRIPLEDES Key Wrap EncryptionMethod
element is a as follows:
<EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#kw-tripledes"/>
The following algorithm wraps (encrypts) a key (the wrapped key, WK) under a TRIPLEDES key-encryption-key (KEK) as specified in [CMS-Algorithms]:
The following algorithm unwraps (decrypts) a key as specified in [CMS-Algorithms]:
Implementation of AES key wrap as specified by NIST/NSA/CMS will be mandatory for AES 128 and AES 256 and optional for AES 192 -- when it has been completely specified by them.
Message digest algorithms can be used in CipherData
to insure integrity, 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 as
described in [XML-DSIG].)
The SHA-1 algorithm [SHA] takes no
explicit parameters. XML encryption implementations MUST implement
SHA-1. 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] takes no
explicit parameters. It is RECOMMENDED that XML encryption
implementations implement SHA-256. An example of an SHA-256
DigestMethod
element is:
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#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-512 algorithm [SHA] takes no
explicit parameters. An example of an SHA-512
DigestMethod
element is:
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#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/2000/09/xmldsig#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.
XML Signature [XML-DSIG] is optional to implement for XML encryption applications. It is the recommended way to provide key based authentication.
Canonical XML [Canon] is the recommended method of consistently serializing XML into an octet stream. If XML is to be later decrypted into a different environment and it is desired to preserve such aspects of its original environment as namespace prefix bindings, the value of attributes in the "xml" namespace, etc., then the Canonical XML With Comments version of the XML should be the serialization that is encrypted
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 nonces in the text being processed.
In accordance with the requirements document [EncReq
] the interaction of
encryption and signing is an application issue and out of scope of
the specification. However, we make the following
recommendations:
Additionally, while the following warnings pertain to incorrect inferences by the user about the authenticity of information encrypted, applications should discourage user misapprension 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.
http://www.ietf.org/internet-drafts/draft-ietf-smime-aes-alg-02.txt