- From: Takeshi Imamura <IMAMU@jp.ibm.com>
- Date: Mon, 3 Jun 2002 01:16:33 +0900
- To: merlin <merlin@baltimore.ie>
- Cc: Ari Kermaier <arik@phaos.com>, xml-encryption@w3.org
Hi Merlin, >Bear in mind that applications that encrypt parts of a signed >document cannot, by definition, be ignorant of XML security >concerns. They must understand that namespaces cannot be >rewritten, whitespace cannot be changed, comments cannot >be stripped, etc. With this in mind, trying to produce >a specification that can undo arbitrary changes made by >arbitrary security-ignorant applications is, in my opinion, >a white elephant. These applications must be aware of the >limitations of the tools that they have available to them. >Multiple encryption is a minor limitation of this tool. I don't agree. I don't still think that limiting multiple encryption makes sense. According to the discussion, it seems that you are concerned about the following: 1. XPointer evaluation 2. Reference to outside of an EncryptedData element I understand that there are some cases where 1 and 2 are not addressed properly, but considering the purpose of decryption transform, I don' think that we should limit the function of the transform for that reason. Rather, I prefer to limit 1 and 2. As for XPointer, all we have to do is to note in the spec that it is recommended to use "#xpointer(id('ID'))". As for reference, the transform is not responsible for whether a reference can be dereferenced or not. If the reference is not dereferenced, the validation will fail, but that is the correct result. Thanks, Takeshi IMAMURA Tokyo Research Laboratory IBM Research imamu@jp.ibm.com
Received on Sunday, 2 June 2002 12:44:04 UTC