- From: merlin <merlin@baltimore.ie>
- Date: Tue, 04 Jun 2002 01:26:51 +0100
- To: "Takeshi Imamura" <IMAMU@jp.ibm.com>
- Cc: xml-encryption@w3.org
Hi Takeshi, r/IMAMU@jp.ibm.com/2002.06.03/01:16:33 >>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. We clearly disagree slightly on the relative importance of multiple encryption and same-document references. However, in my latest proposal (13(rev 2), [1]) I suggest how to support multiple encryption, using an explicit Type that indicates that recursive EncryptedData should be decrypted. Do you have an opinion on this? Does it meet your needs? [1] http://lists.w3.org/Archives/Public/xml-encryption/2002Jun/0000.html >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. While 1 isn't of great concern (although it does matter to some of our customers), I think that 2 is a terrible, inexplicable and unnecessary limitation. As far as I understand it, you are saying that encryptors should be free to encrypt anything in the signed node set without restriction, and in the same breath that they cannot use same-document references or XPointers? Unfortunately I'm not sure we'll ever completely agree on this issue. Merlin
Received on Monday, 3 June 2002 20:28:18 UTC