comments on "Note on XML Encryption"

(the following represents the combined comments of Blair Dillaway, Barb Fox,
and Brian LaMacchia)

Below are several comments in response to the earlier posting of "Note on
XML Encryption" from Takeshi Imamura and Hiroshi Maruyama.  That document is
a reasonable starting point, but we'd like to raise some issues that should
be addressed by the working group.  Looking forward to the meeting next
week.

1. This approach tries to reuse the same mechanisms for both data encryption
and key transport Specifically, the encoding of an  
	   <EncryptedData>
		<EncryptionInfo>
			<KeyInfo>
 			 <EncryptionMethod>
		.....
element structure inside of an <EncryptionInfo><KeyInfo> to handle symmetric
key wrapping using a public key.  We fail to see the benefit of this deeply
nested structure and reuse of tags with different meanings.  A simpler
structure, that makes it clear this is key transport information, seems like
a better choice.  Such a structure, as an immediate child of the
<EncryptionInfo>, might look like
 	  <EncryptionKey>
		<KeyInfo>
			<!-- asymmetric public key >>
		</KeyInfo>
		<EncryptionMethod> ...
		<EncryptedData> ...
	  ...


2. The design separates out encryption KeyInfo, KeyAgreement, and KeySharing
as distinct mechanisms for transmitting information about a symmetric
encryption key.  These are simply options as to how keying information may
be communicated.  To align more cleanly with DSig, these should be unified
into a single mechanism.  In addition, use of this mechanism should be
optional, i.e., the symmetric key may be implied.  Key sharing using a name
key might look like:
   <EncryptionInfo>
	<EncryptionKey>
		<KeyName>foo</KeyName>
	</EncryptionKey>
   ...
Key transport as above, etc.  (Note: The <KeySharing> tag defined in the
Note has no examples of its use )

3. We disagree that encryption meta-data should be an integral part of the
EncryptionInfo.  As the document states, this information varies by
context/application so we can't define any standard structure for this
information.  Some applications may also want to encrypt this meta-data.  We
feel this will be easier if it is a separate XML 'blob' left to the
discretion of the using application.

4. We believe that there's a need to support References from the
EncryptionInfo to the EncryptedData  elements as well as from the
EncryptedData to the EncryptionInfo as indicated in the Note.  What isn't
clear is whether the authors believe both types of references are optional.
We believe they should be.

5. We disagree with the proposed algorithms.  The mandatory algorithm set
should avoid any potential IP encumberences and hence, we suggest that
Diffie-Hellman be dropped.  We would like to see triple-DES and RSA as
recommended and AES mandatory.  

6. It's not clear how one would use the proposed design to handle encryption
to multiple recipients.  We will need to decide how to indicate the
appropriate EncryptionInfo for each recipient, shared use of a single
EncryptionInfo, and so forth.

7. We'd like to see explicit linkage between use of asymmetric keys in
support of encryption and the XML DSig work.  Specifically, we should re-use
the DSig <KeyInfo> definition, rather than creating a new one, when we need
to express asymmetric key information.

Regards,
Blair

Received on Thursday, 26 October 2000 19:11:41 UTC