RE: Exactly how complex is Attribute Encryption

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
element.

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"
       xmlns:enc="http://www.w3.org/xml/encryption/...">

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

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

    <EncryptedData Type="AttributeValue" Name="alt">
      <CipherText>AbCd...WxYz</CipherText>
    </EncryptedData>

  </EncryptedDataManifest>

</video>

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
Christian
discussed at Lafayette.  

Whatever we do, there are some issues to remember:

1. Requiring XSLT for attribute value encryption may be too
processing-intensive
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
good
thing is that it is a very well defined transform with, I hope, no room for
error; 
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
transformations:
using EncryptedDataManifest for encryption of attribute values and external
data
and using transforms for those applications with more elaborate
requirements.

Ed

-----Original Message-----
From: Joseph M. Reagle Jr. [mailto:reagle@w3.org]
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:
>http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0058.html
>I'm also wondering if there's a middle ground between Blair/Phil/Thane's 
>point of view and Ed/Steve/Sanjeev's point of view so the WG could migrate 
>its design if need be once we start getting wider review, and I suspect 
>this would also serve the effort of hitting the end user sweet spot of 
>scope versus complexity (forcing attribute encryption implementation on 
>everyone versus abandoning the requirements of a part of the community.)

I've been thinking some about the above with the idea that a good proto 
design (on something contentious) is one in which a change in requirement 
(supporting, or not, attributes) does not necessitate replacement of design,

but migration. So I've been wondering what exactly are the differences 
required by Ed's proposal and wondering how complex they are compared to the

alternative:

Ed's proposal:

1.  requires a EncryptedDataManifest (since there now can be more than one 
chunks of encrypted data for an element). Easy.
2. a Name attribute which identifies the resource for whom the ciphertext 
applies.
2.1 This could be a Name for which the processor then needs to do a match: 
go parse the tree for an attribute with this name. I'm unsure of the 
complexity but it would need more specification as attribute names 
themselves are not guaranteed to be unique.
2.2 This could also be an XPath which is more straightforward, but then 
requires XPath.
2.3  This also would be useful for "detached" encryption -- not being 
required to always place the EncryptedData in the document Encrypted. This 
could be a feature, and a source of bugs as we already have bidirectional 
key indirections and it could get complicated...

Alternative:

The one alternative that come's to mind is that if an application has 
heterogeneous sensitivity across elements/attributes, it should transform it

into a simple XML (where everything is represented as element+content). 
Would this necessitate XML Encryption add the feature of Transforms?


__
Joseph Reagle Jr.                 http://www.w3.org/People/Reagle/
W3C Policy Analyst                mailto:reagle@w3.org
IETF/W3C XML-Signature Co-Chair   http://www.w3.org/Signature
W3C XML Encryption Chair          http://www.w3.org/Encryption/2001/