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

General principals upon which this specification is based include:

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

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

·Required information should be kept to an absolute
minimum

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

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

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

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

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

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

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

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

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

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

·An XML Element, including the element tags

·An XML NodeList representing the contents of given XML
Element

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

|XML Document
A|

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

|| Encrypted||

||Data-A||

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

||

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

|| Encrypted||

||Data-B||

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

|||KeyInfo|||

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

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

||

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

||Encrypted||

|| Data-C||

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

|||Encrypted|||

|||Key-1|||

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

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

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

While the relationship depicted below is invalid:

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

|
Encrypted|

|Data-A|

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

|| Encrypted||

||Data-B||

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

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

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

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

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

|XML Document
A||XML
Document B|

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

|| Encrypted|||| Encrypted||

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

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

|||||KeyInfo|||

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

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

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

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

||||

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

||Encrypted| |||

|| Data-A| |||

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

|||Encrypted|| |||

|||Key-3|| |||

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

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

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

While the relationship depicted below is invalid:

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

|
Encrypted|

|Key-1|

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

|| Encrypted||

||Key-2||

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

<element name=”EncryptedData”>

<complexType>

<sequence>

<element ref=”xenc:EncryptedKey” minOccurs=0
maxOccurs=”unbounded”/>

<element
ref=”xenc:EncryptionMethod” minOccurs=0/>

<element ref=”ds:KeyInfo”
minOccurs=0/>

<element
ref=”xenc:CipherText”/>

</sequence>

<attribute name=”Id” type=”ID” use=”optional”/>

<attribute name=”Type” type=”string” use=”optional”/>

</complexType>

</element>

Where:

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

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

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

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

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

CipherText is a mandatory element that provides the encrypted data.

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

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

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

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

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

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

<element name=”EncryptedKeyReference”>

<complexType>

<sequence>

<element ref="ds:Transforms"
minOccurs="0"/>

</sequence>

<attribute name="URI" type="uriReference"/>

</complexType>

</element>

Where:

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

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

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

<element name=”EncryptedKey”>

<complexType>

<sequence>

<element
ref=”xenc:EncryptionMethod” minOccurs=0/>

<element ref=”xenc:ReferenceList”
minOccurs=0/>

<element ref=”ds:KeyInfo”
minOccurs=0/>

<element
ref=”xenc:CipherText”/>

</sequence>

<attribute name=”Id” type=”ID”use=”optional”/>

<attribute name=”NameKey” type=”string” use=”optional”/>

</complexType>

</element>

Where:

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

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

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

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

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

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

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

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

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

<element name=”EncryptionMethod”>

<complexType>

<sequence>

<any namespace=”##any”
minOccurs=”0” maxOccurs=”unbounded”/>

</sequence>

<attribute name=”Algorithm” type=”uriReference” use=”required”/>

</complexType>

</element>

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

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

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

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

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

<element name=”CipherText1” type=”ds:CryptoBinary”>

<element name=”CipherTex2”>

<complexType>

<choice>

<element ref=”ds:transforms”
minOccurs=”0”/>

</choice>

</complexType>

<attribute name=”URI” type=”uriReference” use=”required”/>

</element>

Where:

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

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

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

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

<element name=”EncryptedReference”>

<complexType>

<attribute name="URI" type="uriReference"/>

</complexType>

</element>

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

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

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

3. Locate the octet sequence to be encrypted.

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

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

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

4. Build the XML structure for this encryption step

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

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

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

2. Locate the data to be decrypted

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

4. Perform the data decryption operation.

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

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

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

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

<root>

<foo>

<ElementToBeEncrypted>

<a/>

<b>c</b>

</ElementToBeEncrypted>

</element>

</root>

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

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

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

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

<smil>

...

<video src=”secret.mpg”/>

...

</smil>

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

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

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

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

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

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

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

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

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

<EncryptedKey
NameKey?>

<ReferenceList>?

<Recipients>

<Recipient>

<EncrytionMethod>?

<KeyInfo>?

<CipherText>?

</Recipient>+

</Recipients>

</EncryptedKey>

The
authors question whether this extra complexity is justified.

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

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

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

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

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

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

<element
name=”EncryptionInfo”>

<complexType>

<sequence>

<element
ref=”xenc:EncryptedKey” minOccurs=0 maxOccurs=”unbounded”/>

<element
ref=”xenc:ReferenceList” minOccurs=0/>

<element
ref=”ds:KeyInfo” minOccurs=0/>

</sequence>

<attribute name=”Id”
type=”ID” use=”optional”/>

</complexType>

</element>

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

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

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

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

<KeyInfo>

<EncryptedKey>

<KeyInfo>

<EncyrptedKey>

<KeyInfo>

...

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

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

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

<AccountInfo>

<AccountType>S</AccountType>

<AccountNumber>123456</AccountNumber>

</AccountInfo>

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

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