Re: Comments on the requirements draft

At 15:07 3/19/2001 -0800, Blair Dillaway wrote:
>Attached are my comments on the XML Encryption Draft Requirements 
>document.  Since there are quite a few edits/comments, I've made them 
>directly in the document.

Hi Blair,

Thank you for the comments, and the useful way of annotating the document. 
The resulting document (with most of the changes merged in) is at:

http://www.w3.org/Encryption/2001/03/21-xml-encryption-req.html

Those issues I'm unsure of, or did a major tweak on your tweak are still red.

>The XML representation of the encrypted resource must be a first class 
>object that can be readily distinguished from other types of information in 
>a given XML document.

I believe I originally introduced this "first class object" terminology 
based on something written by TimBL. However, in the dsig context I realized 
its not well understood (it basically means it can be referenced, signed, 
etc. Also, what do you mean by "readily distinguished"? (What's the counter 
case of that sort of requirement?)

>But, it is also recognized that encrypting attribute values always 
>transforms the original document.  In general, this transformation will 
>make the resulting document invalid against an existing, non-encryption 
>aware, schema, for the original document.  Hence, intermediate processors 
>may error when attempting to process the encryption transformed document. 
>The XML Encryption specification should not encourage this potentially 
>brittle application behavior. {Dillaway}

The point I failed to make at the FTF is that I agree this sort of transform 
will necessarily make the document useless  to non-encryption aware 
processors. Encryption of attribute values would do the same. My concern is 
that it will make the document useless to encryption aware (but without a 
key)  processors. (Basically, I think to be fair that without an actual 
specification of this transform and scenario/example, we should clearly 
represent that those that have the requirement of attribute encryption are 
simply out of luck as there is no demonstrated solution.)

For instance:

         <person first="joseph" last="reagle" ssn="555-55-5555">is 
smiling</person>

If the ssn value becomes encrypted for Alice, but I still want intermediate 
encryption aware processors (that can't decrypt) to use the data in the 
clear, they can.

         <person first="joseph" last="reagle" enc:Attribute="alksjd">is 
smiling</person>

An encryption aware processor without the key can just ignore that attribute.

Now, if I do a transform with the following result:

<person>
   <enc:childProperties>
     <enc:Content>is smiling<enc:Content>
     <enc:first>joseph</enc:first>
     <enc:last>reagle</enc:last>
     <enc:EncryptedData>...</enc:fEncryptedData>
   </enc:childProperties>
</person>

This isn't readily useful to encryption aware (but without a key) 
intermedaries. But that's not my big concern. What I'm unsure of is 
*without* the ability to decrypt, I don't think it's possible to apply the 
transform's inverse. Maybe it is, but I'm not sure and get concerned in 
scnearios of what happens if someone wanted to encrypt an attribute and the 
content.

Regardless,  by  "The XML Encryption specification should not encourage this 
potentially brittle application behavior. " you mean that even if a 
transform and inverse did exist, we shouldn't encourage it?

>The specification must allow super-encryption

Ok, moved to super-encryption in both documents.

>The result of super-encrypting elements must result in valid XML with 
>respect to the XML Encryption specification.

s/$above/Super-encrpted data must use the same syntax and semantics as any 
other encrypted data/.

>in an XML compatible manner... The XML key information structure must be a 
>first class object that can be readily distinguished from other types of 
>information in a given XML document.

Struck this as not sure what it means (see earlier point.) Do we want a 
simple requirement that while EncrypedKey is like EncryptedData, the syntax 
must represent them as different.

>1. Each encrypted data object must not be required to rely upon other 
>encrypted data, references or dependencies.
>2. It should be possible to express key information objects as valid 
>independent XML, or as part of an encrypted data object.

Ok, tweaked the text of these a little in the doc.

>I suggest we remove this section.  I nitialization vector requirements are 
>algorithm specific and they be discussed in that context, if necessary at 
>all.

Where should we move it to? Given all the discussion, I think we should 
mention it somewhere...


I like your clean up of the security requirements, still left one bit red as 
I'm hesitant to drop references to potential security weakeness if we're not 
confident we've addressed them.


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

Received on Wednesday, 21 March 2001 19:41:59 UTC