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 Friday, 4 May 2001 12:52:23 UTC