Re: Comments on the 6 Apr Draft

Blair,

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

I believe, though the distinction between "Element" and
"ElementChildNodeList" may be eliminated into something like "NodeList",
the distinction between the "NodeList" and "Document" should not be
eliminated.  This is because a document may also contain a document type
declaration and so it cannot be processed (i.e., deserialized or
unmarshaled) in the same way as a node list.

Thanks,
Takeshi IMAMURA
Tokyo Research Laboratory
IBM Research
imamu@jp.ibm.com



From: "Blair Dillaway" <blaird@microsoft.com>@w3.org on 2001/05/05 01:50 AM

Please respond to "Blair Dillaway" <blaird@microsoft.com>

Sent by:  xml-encryption-request@w3.org


To:   <xml-encryption@w3.org>
cc:
Subject:  Comments on the 6 Apr Draft



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.

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.

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.

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

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

The KeyRetrievalMethod element provides a way to express a link to an
EncryptedKey element containing the key needed to decrypt the CipherData
associated with an EncryptedData or EncryptedKey element.  The
KeyRetrievalMethod  is always a child of the enc:KeyInfo element and may
appear multiple times.  If there is more than one instance of a
KeyRetievalMethod in a KeyInfo, then the EncryptedKey objects referred
to must contain the same key value, possibly encrypted in different ways
or for different recipients.

     <existing  schema fragment>

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

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.

Regards,
Blair Dillaway
Microsoft Corp.

Received on Tuesday, 8 May 2001 04:23:27 UTC