RE: Exactly how complex is Attribute Encryption

Joseph wrote:
I still find it confusing that the Name takes the value an attribute name 
*and* an attribute value. Seems to me that if we do attribute encryption, we

shouldn't be "chasing links": we should only encrypt those things that are 
in the documents Infoset, meaning take the literal value and encrypt it 
regardless of whether its type is string or uriReference -- (to use 
"validating" terminology though we will likely be encrypting non-validating 
data too).
--- END OF QUOTATION ---

Would you find it more consistent to think of the Name attribute as a URI,
perhaps even renaming it accordingly? In this case, when encrypting an
attribute value, the Name attribute on the associated <EncryptedData>
element would use the XPath notation as in "@src".  The Name="secret.mpg" 
would remain the same because it is already a URI.


Joseph wrote:
So, if you wanted to encrypt the mpeg and the attribute value:

  <video src="secret.mpeg" type="video/MPV" alt="secret footage">

(Note, it's the application that should be worrying about the MIME type at 
this point) the resulting syntax would be:

   <video src="secret.xml" type="text/xml" enc:EncryptedAttribute="#enc1">
     <EncryptedDataManifest xmlns="">
       <EncryptedData ID="enc1" Type="AttributeValue">
         <CipherText>AbCd...WxYz</CipherText>
       </EncryptedData>
     </EncryptedDataManifest>
    </video>

(Note, I changed the attribute from alt to enc:EncryptedAttribute).

And the mpeg has been encrypted as such:

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

An application will find this data, call the XML handler, which sees the enc

namespace, and decrypts it appropriately.
--- END OF QUOTATION ---

Here are my two major difficulties with the above proposal:

1.  I have trouble with altering the value of the src attribute; the value
of
the attribute is not secret, and by altering it, other applications are
prone
to misinterpreting it (eg. "show me a list of the MPEGs used by this file").
As well, in your example, how would a receiving app even know the value of
src
was changed and that there is some connection between 
EncryptedData[@Name="secret.mpg"] and video[@src="secret.xml"]?

2.  In your example, not only the attribute value is encrypted but also the
name of the attribute itself.  I have no problem with supporting the feature
but I'm not sure that it is generally seen as a requirement for XML
Encryption.  
If it becomes one, we have to remember that an element might have more that
one attribute name-value pair to be encrypted so we cannot get away with 
just enc:EncryptedAttribute.  That is why I prefer the idea of the
EncryptedDataManifest attribute because it is just too messy to try and
handle,
through multiple XML Encryption namespace attributes, all the different
nodes
and URIs that an application might want to encrypt for a particular element.

Though it may be necessary in some cases, my expectation is that
applications 
will want to avoid encrypting the name of the thing being encrypted.
Because
once the name is encrypted, its much harder to get handle the object.  Can 
someone suggest a practical example where it makes sense to encrypt the name

of an object as well as the object itself.

Ed
-----Original Message-----
From: Joseph M. Reagle Jr. [mailto:reagle@w3.org]
Sent: Thursday, February 22, 2001 6:32 PM
To: Ed Simon
Cc: Public XML Encryption List
Subject: RE: Exactly how complex is Attribute Encryption


At 17:55 2/22/2001 -0500, Ed Simon wrote:
>    <EncryptedData Type="video/mpeg" Name="secret.mpg">
>       <CipherText URI="secret.enc"/>
>     </EncryptedData>
>
>in the <EncryptedDataManifest> tells the element processor that if needs 
>the data for "secret.mpg" then it will need to decrypt the ciphertext 
>located at "secret.enc".

I still find it confusing that the Name takes the value an attribute name 
*and* an attribute value. Seems to me that if we do attribute encryption, we

shouldn't be "chasing links": we should only encrypt those things that are 
in the documents Infoset, meaning take the literal value and encrypt it 
regardless of whether its type is string or uriReference -- (to use 
"validating" terminology though we will likely be encrypting non-validating 
data too).

So, if you wanted to encrypt the mpeg and the attribute value:

  <video src="secret.mpeg" type="video/MPV" alt="secret footage">

(Note, it's the application that should be worrying about the MIME type at 
this point) the resulting syntax would be:

   <video src="secret.xml" type="text/xml" enc:EncryptedAttribute="#enc1">
     <EncryptedDataManifest xmlns="">
       <EncryptedData ID="enc1" Type="AttributeValue">
         <CipherText>AbCd...WxYz</CipherText>
       </EncryptedData>
     </EncryptedDataManifest>
    </video>

(Note, I changed the attribute from alt to enc:EncryptedAttribute).

And the mpeg has been encrypted as such:

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

An application will find this data, call the XML handler, which sees the enc

namespace, and decrypts it appropriately.

I'm sure I'm still not completely grokking your proposal, but could you tell

me if my proposal fails to me any of your requirements?

__
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/