Re: Comments on the 6 Apr Draft

[Resulting version:
        http://www.w3.org/Encryption/2001/05/11-proposal.html
        Includes changes from feedback from Dillaway, Schaad,
        Simon, Takeshi, and Schaad/Farrell .]

At 09:50 5/4/2001 -0700, Blair Dillaway wrote:
>Below are comments on the latest rought draft.  I've tried not to repeat
>issues/problems already posted by others.
>
>2. - In the example, it shows a CipherData element with a URI attribute
>and an 'encrypted' value.  Mixing these together doesn't track with
>proposed syntax. The expectation is that one has an element with a URI
>reference and optional Transforms, or the actual encrypted data as
>base64Binary.  We've discussed separating these two constructs out as
>separate types.  I assume once this is done we can clean up the example.

This pseudo-BNF (that Don came up with for dsig) is supposed to simply show 
what is possible: exercises all the syntax and decorate them with {+,*,?}. 
I've tried to improve it, now:
           <CipherData (URI='')?>(encrypted character data)?</CipherData>

>2.1.1 - in the example, the CipherData closing tag has an 'enc' prefix
>while the opening tag doesn't and the 'enc' prefix isn't specified.  The
>prefix should be removed.

fixed.

>3.1 - The text (paragraph 3) states "KeyInfo is an optional element,
>defined by [XMLDSIG], ...".  While correct, the EncryptedType schema
>includes a KeyInfo element defined in the Encryption namespace, not the
>DSIG namespace.  One would presumably need to read the complete schema
>to find out how DSIG KeyInfo and Encryption KeyInfo relate.  If we stick
>with this schema then the text should be updated to explain the
>relationship.

Yes, I've now reintegrated the latest version of my working schema into the 
text -- which uses ds:KeyInfo.

>3.4 - under bullet item 1.1.2, the text should be "... indicate a key
>known ..." not "... indicate a key know ..."

ok.

>3.4.2 - Here is my suggested re-write of the textual material in this
>section.  The schema fragment should remain as is.
>...

ok

>KeyRetrievalMethod uses similar syntax and dereferencing behavior to the
>RetrievalMethod element in [XMLDSIG], except the type attribute is
>implicitly of type EncryptedKey.

This goes back to my point of what rely upon a change of the element type 
and an implicit type? Why not just use RetrievalMethod 
Type="&enc;#EncryptedKey". It'd be much more consistent with dsig.

>4.  I would like to suggest we eliminate the distinction between an
>encrypted "Element" and "Element ChildNodeList" in this discussion.  The
>rules can be generalized, when encrypting/decrypting XML information, to
>the case that we have an ordered collection of one or more sibling XML
>Nodes.  The "Element" type processing is simply the degenerate case
>where the collection contains a single Xml Node (and its children) that
>is of type Element.  This can be processed in the same manner as the
>case where we have multiple sibling Nodes.  I believe this will also
>allow us to describe encryption of an entire XML document without
>introducing another special case.  In the document case, the collection
>of sibling XML Nodes to be encrypted/decrypted may include processing
>instructions, comments, namespace declarations, etc. in addition to the
>root Xml Element.

Like Takeshi, I think an XML document is processed differently. Unlike 
Takeshi, given the first agreement with him, I don't understand what this 
proposal then provides. Yes, Element and childNodes can both be considered 
nodes, but I'd think the specific information would be useful, and if we 
used only NodeList, it could include things other than elements, which we 
then have to constrain using natural language in the spec which might be 
awkward...



__
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 Friday, 11 May 2001 18:05:11 UTC