Re: Kudos and Comments on XML Encryption Requirements working draft

[Resulting version:
         http://www.w3.org/Encryption/2001/Drafts/xml-encryption-req.html
        $Revision: 1.2 $ on $Date: 2001/05/17 19:08:19 $ by $Author: reagle $
]

At 12:32 4/23/2001 -0400, Eric Miller wrote:
>XML Encryption Requirements working draft
>http://www.w3.org/TR/2001/WD-xml-encryption-req-20010420
>
>Joseph, per your request,...
>the following is a brief review of this document.

Thanks, here's my belated response!

>Specific Comments:
>
>Section 1, Item 1:
>
>"The XML representation of the encrypted resource must be a first
>class object (i.e., referenced) and represented by a distinct element
>type."
>
>and then later...
>
>Section 1, Item 1, SubItem 1:
>
>"Granularity of encryption is limited to an element (including
>start/end tags) or element content (between the start/end tags)."
>
>- Question/Clarification: So for clarity (perhaps only in my mind?)
>every resource, and element, and element content must be uniquely
>identifiable.  Is so, please make explicit, if not, please clarify.

These are slightly different issues. First, the structures we create are " 
referenceable and consequently describable, signable, etc." Second, the 
structures we encrypt are limited to element's, their content, and arbitrary 
data.

>Section 2, Item 1:
>
>"1.It must be possible to indicate the original type (i.e., XML CData,
>image/gif) of the encrypted data to aid the decryptor in processing
>it.  For non-XML data, existing MIME type definitions [MIME] should be
>used."
>
>- Question/Clarification: If it is possible to encrypt to the
>granularity of element or element content, is the MIME type to be
>assumed to be the encapsulating resource? Or can this be something
>different?

"*For non-XML data*". If the data is XML, one could use text/xml but you'll 
be using one of the identifiers we create to describe it (e.g,. a  URI that 
denotes a DOM element interface, or Infoset element info item).


>Section 2, Item 3:
>
>"3.The specification must allow super-encryption of data (i.e,,
>encrypting XML in which some elements are already encrypted). {prop1,
>prop2}Super-encrpted data must use the same syntax and semantics as
>any other encrypted data."
>
>- s/i.e,,/i.e.,
>- s/Super-encrpted/Super-encrypted

Ok.

>- Question/Clarification: I'm assuming here this is akin to
>RDF/Semantic Web's notion of "one persons metadata is another persons
>data"?  In that one could imagine, for example, this notion of
>super-encryption applying to an individual encrypting individual files
>in a directory, and then someone else encrypting (perhaps even using a
>different algorithm) the entire directory.  Correct?  If so, this has
>interesting overlap/implications/relationships with the Semantic Web
>community.

This is correct. What I'm trying to recall is if we won't support the 
encryption of a pre-existing EncryptedData's children. WG, is this correct, 
should this be added as a requirement?

>Section 2, Item 5:
>
>"5.The specification must define a minimal set of algorithms and key
>structures necessary for interoperability purposes. {Reagle}"
>
>- I would additionally suggest include the capabilities of formally
>extending this set of algorithms and key structures.

minimal /+(extensible)+/ set

>Section 3, Item 1:
>
>"The WG is still working on this issue in the context of our XML
>processing model and its relationship to tree and event based
>parsers."
>
>- I would include the suggestion of additional coordination with the
>larger XML Activity regarding to processing model.

I'm working on it!

>Section 3, Subsection 1, Item 2:
>
>"1.When a non-XML object (i.e., external data) is encrypted, the
>information necessary to aid the recipient in decrypting the object is
>captured in an instance of XML."
>
>- Question/Clarification: What does this information necessary to aid
>the recipient in decrypting the object look like?  Is this a separate
>metadata file?  If so, what are the minimal characteristics required
>for decryption?

It's everything but the CipherData, including the encryption method and key 
info. Now: When a non-XML object (i.e., external data) is encrypted, the 
information necessary to aid the recipient in decrypting the object is 
captured in an instance of XML (i.e. the encryption method, keying 
information, etc.).

>Section 3, Subsection 2, Item 1:
>"(i.e., XML CData, image/gif)"
>- s/CData/CDATA

ok.

>Section 4, Item 2:
>
>"2.The specification must specify or reference one mandatory to
>implement algorithm for only the most common application scenarios. "
>
>- Suggestion/Comment: I would suggest giving these algorithms URIs to
>minimize potential ambiguity.

Yep, we always do this (and include parameterization information if 
necessary in children elements of the structure contrain the <Algoirthm 
URI="">

__
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 Thursday, 17 May 2001 15:12:02 UTC