Re: Decryption Transform processing question

I agree -- multiple decryption appears to cause more trouble than it's 
worth. Perhaps we should draft language for the processing rules that would 
limit the transform to one level of decryption (should be fairly easy to 
agree upon), and leave the Type information processing (potentially 
difficult to get right) for a subsequent revision afterward?

Ari

>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
>
>
>-----------------------------------------------------------------------------
>The information contained in this message is confidential and is intended
>for the addressee(s) only.  If you have received this message in error or
>there are any problems please notify the originator immediately.  The
>unauthorised use, disclosure, copying or alteration of this message is
>strictly forbidden. Baltimore Technologies plc will not be liable for
>direct, special, indirect or consequential damages arising from alteration
>of the contents of this message by a third party or as a result of any
>virus being passed on.
>
>This footnote confirms that this email message has been swept for Content
>Security threats, including computer viruses.
>http://www.baltimore.com

Received on Thursday, 30 May 2002 18:21:14 UTC