Review of "Note on XML Encryption"

Takeshi and Hiroshi,
I think the Note on XML Encryption is a big step forward with respect to 
defining <EncryptionInfo>.  Its great to see such progress. Here are my
comments:

1.  I lean gently toward renaming <EncryptionInfo> as <DecryptionInfo>
because
its ultimate purpose is to provide information on decrypting the data.  This
is
a minor point.

2.  As you say, an <EncryptionInfo> element can point to one or more
<EncryptedData>
elements, or an <EncryptedData> element should be able to point to an
<EncryptionInfo>
element.  I would just clarify that an <EncryptionInfo> element can both
point to
<EncryptedData> elements AND also be referenced by <EncryptedData> elements
at the
same time.

3.  Use the element name <EncryptedKey> rather than
<EncryptedData> when the content is an encrypted key inside
<EncryptionInfo>.
It is true that the structure of <EncryptedData> is valid when the content
happens
to be a key but the semantics are meaningfully different for applications.
<EncryptedData> should be reserved for data corresponding to the plaintext
instance being
secured and not for keying material introduced by the encryption process.  
Using <EncryptedData> for both application data and keying material will
require either
an ancestor search or attribute check for an application to determine
whether the 
content is application data or not.  For stream based parsers, these checks
would likely
be particularly annoying.  To keep things straight-forward for applications
and ourselves, 
let's use different tag names.

4.  Here's an idea for handling IVs and other <EncryptionInfo> data.  

If an <EncryptedData> element contains no <EncryptionInfo> element AND has
no EncryptionInfo 
attribute pointing to an <EncryptionInfo> element, it is assumed the
application can figure 
out the encryption info by itself.  (This is analagous to an absent
<KeyInfo> element in
XML Signatures.)

If an <EncryptedData> element has EITHER, but NOT BOTH, a child
<EncryptionInfo> element
or an EncryptionInfo attribute, there is only one associated
<EncryptionInfo> element and
that on is used.  No problem here.

If an <EncryptedData> element has BOTH a child <EncryptionInfo> element AND
an EncryptionInfo
attribute, it combines the two giving priority to its child <EncryptionInfo>
element where
specific parameters conflict (eg. an IV).  

If the resulting <EncryptionInfo> element has no parameter for something
(say, an IV), it is
assumed that the application can handle that situation.

My hope is the above would provide a flexible way of handling the various
encryption scenarios
(such as encrypted video) that were discussed at Santa Barbara and on the
XML Encryption
mailing list.

5.  I would structure <EncryptionInfo> (which I think might be better 
termed <DecryptionInfo>) as follows:

<DecryptionInfo (Id=)?>
  <Method Algorithm=""/>
  <PropertyList>
	<Property Name="IV">1234...</Property>+
  </PropertyList>
  <Manifest>
	<Reference.../>+
  </Manifest>
  <KeyInfo>
	<Value/>?
      <Identifier/>?
      <Agreement/>?
      <EncryptedKey/>+
  </KeyInfo>
</DecryptionInfo>

I put the <Reference> elements in a <Manifest> element simply because I like
to see lists
of the same elements structurally distinct; this is mainly a personal
preference.  <KeyInfo>
is at the bottom because this will often be a relatively huge chunk of data
and I think
it makes performance better if an application doesn't have to parser through
a bunch of stuff
it doesn't need to get to what it is looking for.  I've also made it
possible for <KeyInfo>
to hold one or more types of key data so that an application can
simultaneously provide multiple
ways of specifying the key.  (Do people think this is a good idea?  I've not
completely researched
it myself.)

Looking forward to discussing this more in Lafayette, Ed