RE: Exactly how complex is Attribute Encryption

We haven't discussed this topic on the list for three weeks so for ease of
discussion, let me imbed the original approach from [1] where one has

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

and one wants to encrypt

a) the value of the alt attribute and
b) the MPEG file named secret.mpg

I have proposed the following strawman for the syntax of the result:

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

where the presence of the EncryptedDataManifest attribute in the <video>
element indicates that there is encrypted data that MAY need to decrypted
when processing the element.  The value of the EncryptedDataManifest
attribute points to the location of the <EncryptedDataManifest> element
which holds the encrypted data (or by default, we could mandate it be the
first child of the element in question).  


Joseph wrote 
You seem to be relying upon the Name to indicate what has changed. However, 
in one instance the value of Name corresponds to the original attribute 
value (secret.mpg), and the other to the attribute itself (alt). The first 
could be ambiguous because attribute values are not necessarily unique 
within an element. (There could be two attributes with the value of 
"secret.mpg"). Also, I don't understand the relationship between secret.mpg 
and secret.enc, are you encrypting the value, or the referent of the value 
when its a uriReference type? I'm not sure how you would do the later and 
I'd recommend just focusing on encrypting the .
--- END of quotation ---

Yes, the value of the Name attribute indicates the name of the resource that
was encrypted whether that resource was an attribute value or external data.
The purpose of the EncryptedDataManifest element is to be a holder for
non-child-node data associated with an element such as attribute values or
external data.  Despite the title of this thread, EncryptedDataManifest is
for any time of non-child-node data not just attribute values.

In the case of the <video> element's src attribute, I am encrypting the
referent of the attribute value which is the MPEG file itself, what the
value of the attribute refers to.  The attribute value need not be encrypted
so it should remain unchanged.  I do not see any problem with have two or
more attributes both having the value "secret.mpg".  The existence of

    <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".  There is no explicit binding to any attribute in the <video>
element so it does not matter how many attributes have a value of
"secret.mpg".  In fact, even if there was no attribute with the value
"secret.mpg", the semantics remain the same: if the element processor needs
the data for "secret.mpg" then it will need to decrypt the ciphertext
located at "secret.enc".

Could you explain why you don't see how "secret.mpg" could be encrypted.  As
I understand URIs/URLs/URNs, and please correct me if I am wrong, a URI may
relate closely to a physical path (URL) or it may be an alias like an URN.
My guess is that someone implementing encrypted video on the web would make
"secret.mpg" an alias which really points to the encrypted MPEG stored at
URL "secret.enc".  

Ed

-----Original Message-----
From: Joseph M. Reagle Jr. [mailto:reagle@w3.org]
Sent: Thursday, February 22, 2001 4:03 PM
To: Ed Simon
Cc: Blair Dillaway; Phillip hallam-Baker; Public XML Encryption List
Subject: RE: Exactly how complex is Attribute Encryption


Ed,

I've been thinking about this proposal [1] but had some questions first.

[1] http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0106.html

You seem to be relying upon the Name to indicate what has changed. However, 
in one instance the value of Name corresponds to the original attribute 
value (secret.mpg), and the other to the attribute itself (alt). The first 
could be ambiguous because attribute values are not necessarily unique 
within an element. (There could be two attributes with the value of 
"secret.mpg"). Also, I don't understand the relationship between secret.mpg 
and secret.enc, are you encrypting the value, or the referent of the value 
when its a uriReference type? I'm not sure how you would do the later and 
I'd recommend just focusing on encrypting the . (Also, there may be some 
empty elements of the form <video/> which you will be forcing into a pair 
element with content <video>...</video>, but we're changing the content 
model in other ways, so this isn't a biggie.)

The way I could understand it better would be to simply replace the attr 
value. So in the following instance, if I want to encrypt the external 
resource *and* the attribute value of the alt:

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

I would alter it to:

   <video src="secret.xml" alt="#enc1">
    <EncryptedDataManifest>
      <EncryptedData ID="enc1" Type="AttributeValue">
        <CipherText>AbCd...WxYz</CipherText>
      </EncryptedData>
    </EncryptedDataManifest>
   </video>

and there's a seperate resource called secret.xml that looks like:

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



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