W3C home > Mailing lists > Public > xml-encryption@w3.org > May 2002

Re: Decryption Transform processing question

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
Message-Id: <20020530201733.0690B4432D@yog-sothoth.ie.baltimore.com>

>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:
    <Something> <SignedPart Id="SignedPart" /> </Something>
    <Signature URI="#SignedPart"> ... decrypt# ... </Signature>

If an application encrypts this so:
    <EncryptedData ... />
    <Signature URI="#SignedPart"> ... decrypt# ... </Signature>

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.

Received on Thursday, 30 May 2002 16:18:43 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:09 UTC