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

Re: Decryption Transform processing question

From: Ari Kermaier <arik@phaos.com>
Date: Thu, 30 May 2002 15:44:54 -0400
Message-Id: <>
To: reagle@w3.org, merlin <merlin@baltimore.ie>
Cc: "Takeshi Imamura" <IMAMU@jp.ibm.com>, xml-encryption@w3.org

>On Thursday 30 May 2002 01:23 pm, Ari Kermaier wrote:
> > I had not considered the sort of document structure that Merlin used to
> > illustrate potential ambiguities arising from the processing rules.
> > Merlin makes a good point on this subject -- I'm just not sure I
> > understand his proposal for dealing with super-encrypted elements by
> > using multiple DecryptTransform elements in the dsig:Reference.
>Hrmm... Yes, I was advocating for layers/wrappings/peeling, but then again
>if someone adds a layer of super-encryption, the whole point of this
>transform is to create a signature that works regardless of encryptions
>done in the future (since that's impossible to know.) One can't go back and
>add a Transform to a Signature, you'd break it...

Yes, that was my thinking as well, and it works nicely in most situations. 
Unfortunately, as Merlin's example illustrates, the spec doesn't handle 
every case. I really like the idea of enabling, for example, workflow 
applications that can correctly sign-and-encrypt a document without knowing 
all the details of what sort of encryption was done at a previous stage. 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).

Received on Thursday, 30 May 2002 15:43:21 UTC

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