

RE: Exactly how complex is Attribute Encryption

From: Ed Simon <ed.simon@entrust.com>
Date: Wed, 31 Jan 2001 22:05:30 -0500
Message-ID: <A0E1DEC54ED42F4884DD9EEA00ACE37106D0DD@sottmxs08.entrust.com>
To: "'Joseph M. Reagle Jr.'" <reagle@w3.org>, Blair Dillaway <blaird@microsoft.com>, Phillip hallam-Baker <pbaker@verisign.com>
Let me reword and slightly correct Joseph's explanation of my proposal.

To encrypt one or more attributes of an element:

1.  Add an EncryptedDataManifest attribute (XML Encryption namespace)
to the element to indicate that there is an
EncryptedDataManifest element (XML Encryption namespace) associated
with the attribute.  Basically, we are signifying that there is 
encrypted data (attribute values or external arbitrary data) that
may need to be considered when the element is processed.

2.  Specify the value of the EncryptedDataManifest attribute as
"./EncryptedDataManifest" to indicate that the EncryptedDataManifest
element is a child of the element in question.  This model could be
extended to allow pointing to an EncryptedDataManifest element
at any URI but I'm not sure if this is a good idea.  We may want to
mandate that EncryptedDataManifest must always be a child of the

3.  Create an element named EncryptedDataManifest (XML Encryption
namespace) and add an EncryptedData child element for each attribute
value or arbitrary data to be encrypted.  For attribute values,
specify the EncryptedData element's Type attribue as "AttributeValue"
and the Name attribute as the attribute's name.  Specify the encrypted
value of the attribute as the value of the CipherText element.

For arbitrary data, the value of the Type attribute is the data's MIME
type and the value of the Name attribute is the name the application uses
to identify the arbitrary data.

4. Delete the attribute (with its plaintext value) from the element.

For example,

<video src="secret.mpg" alt="Alien spaceship in hangar at Area 51."/>

would become

<video src="secret.mpg" enc:EncryptedDataManifest="./EncryptedDataManifest"

  <EncryptedDataManifest xmlns="http://www.w3.org/xml/encryption/...">

    <EncryptedData Type="video/mpeg" Name="secret.mpg">
      <CipherText URI="secret.enc"/>

    <EncryptedData Type="AttributeValue" Name="alt">



Note that there is no ambiguity in the attribute name because the element
knows which EncryptedDataManifest attribute is associated with it.

Here's a summary of my view on transforms:

1.  One view is that XML Encryption should not mention transforms.  If an
application wants to encrypt an XML instance's attributes, it can, upon 
encryption, transform itself into a variant where the attributes become
elements and then encrypt away.  Upon decryption, it would decrypt the
transformed-then-encrypted XML instance and do the reverse transform.

The problem I have with this is that we introduce an application-dependent
step in XML Encryption and that seems to me to defeat the purpose of trying
to standardize XML Encryption.  

2.  Another view is XML Encryption should mention transforms.  In other
appends, I have pointed out that we cannot just use transforms like
XML Signature does.  XML Signature transforms extract the data to be signed
whereas the XML Encryption transforms must NOT lose any of the original
plaintext data while transforming the XML structures to be encrypted.
This is part of making the transform reversible.  On the decryption side,
one also must ensure that no data, whether it was encrypted or not, is lost.
If we discuss transforms in XML Encryption, we would likely need to specify
a detailed how-to section which might need to be normative.  Such a section
would have to cover gotchas like whitespace, default attributes, namespaces,
etc. which wouldn't be impossible but not really something we should start 
until we agree this is something we want to do.

It is my feeling that supporting transforms in encryption was more
complexity than the WG wanted.  However, if we did do it, then we would be
able to support all sorts of interesting applications such as the one
discussed at Lafayette.  

Whatever we do, there are some issues to remember:

1. Requiring XSLT for attribute value encryption may be too
for some applications.

2. XSLT Transformations don't support encrypting external data associated
with an 
element (eg. <img src="secret.gif"/>) whereas EncryptedDataManifest does.

3. Basically, EncryptedDataManifest is, under the covers, a transform.  The
thing is that it is a very well defined transform with, I hope, no room for
the alternative of letting applications specify their own XSLT
transformations leaves
too much responsibility for "doing it right" with the application.

4. The option exists to support both EncryptedDataManifest and
using EncryptedDataManifest for encryption of attribute values and external
and using transforms for those applications with more elaborate


-----Original Message-----
Sent: Wednesday, January 31, 2001 4:46 PM
To: Blair Dillaway; Ed Simon; Phillip hallam-Baker
Cc: Public XML Encryption List
Subject: Exactly how complex is Attribute Encryption

In a previous message I wrote:
>scope versus complexity (forcing attribute encryption implementation on 


but migration. So I've been wondering what exactly are the differences 


Ed's proposal:

chunks of encrypted data for an element). Easy.
complexity but it would need more specification as attribute names 
themselves are not guaranteed to be unique.
requires XPath.
required to always place the EncryptedData in the document Encrypted. This 
key indirections and it could get complicated...


heterogeneous sensitivity across elements/attributes, it should transform it

Would this necessitate XML Encryption add the feature of Transforms?

W3C Policy Analyst                mailto:reagle@w3.org
Received on Wednesday, 31 January 2001 22:06:20 GMT
