- From: merlin <merlin@baltimore.ie>
- Date: Thu, 30 May 2002 21:17:32 +0100
- To: Ari Kermaier <arik@phaos.com>
- Cc: xml-encryption@w3.org
r/arik@phaos.com/2002.05.30/15:44:54 >I really dislike the thought that the transform could break in unpredictable >ways in some circumstances. I don't have a concrete proposal that addresses >both concerns. Merlin's proposal seems to address situations where >super-encryption is tightly controlled by the application, but it doesn't >seem sufficiently flexible to me (unless I'm failing to understand how >multiple layers of encryption are decrypted). I do not believe that there is a perfect solution; nor do I believe that we need a perfect solution; and, as you correctly understand, I do not propose a solution to the problem of multiple encryption. I instead propose what I think is the best compromise: a transform that works well, in a predictable and intuitive manner, and solves most common needs. The one clear and documented (well, it could be) limitation is that multiple encryption will not be unwrapped, except through the application of multiple decryption transforms. This will solve the problem where an application can predict that multiple encryption may occur. Otherwise, multiple encryption is simply not a problem that we can reasonably solve. Consider this document: <Document> <Something> <SignedPart Id="SignedPart" /> </Something> <Signature URI="#SignedPart"> ... decrypt# ... </Signature> </Document> If an application encrypts this so: <Document> <EncryptedData ... /> <Signature URI="#SignedPart"> ... decrypt# ... </Signature> </Document> Our transform cannot solve this. As with most things, the solution I propose has some limitations. Things otherwise work reasonably efficiently and well. 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. Merlin
Received on Thursday, 30 May 2002 16:18:43 UTC