RE: [wss] Re: Issue 84 - Use of Decryption Transform

["Hal Lockhart" <hlockhar@bea.com>]

Mike wrote: 
> When there are more than one security header, the decryption 
> transform may
> be necessary to provide the processing order required to 
> verify a signature
> that references elements that may have been encrypted for other
> roles/actors prior or subsequent to the application of the 
> signature. Since
> one SOAP Node may perform multiple role(s)/actor(s), this 
> information could
> be used by that node to: a) order the role/actor processing, or b) to
> reroute the message to another node.

At the moment, this seems like hand waving. Let us look at specific cases below.

> > (Note, this prohibition only applies to signatures in the security
> > header. Applications can include signatures which specify the
> > decryption transform in the body. WSS will neither prohibit 
> or process
> these.)
> 
> Do you presume that all WSS processing would occur for all 
> roles/actors
> before any application level XML sig/enc processing at any 
> role/actor? 

This seems irrelevant to me, but come to mention it, no.

1. I am already on record as saying Security should be the outermost layer on the stack (first on input, last on output.)

2. I have always assumed that a node acting in several roles would act as if it were several nodes and process all the headers addressed to each role (in the normal order) before passing on to the next role. (As a side note, it is not clear to me if a message passing thru intermediary is supposed to traverse all the layers twice, in and out. This is of course how routers work. This suggests that a node supporting several roles should do this for every role except ultimate receipient, even if the node was the last one.
 
>Even
> in a case with only one security header, there could be other headers
> targeted to roles/actors that use non-WSS XML sig/enc where 
> the tranform
> could be used to avoid conflict.

Yes, but this case is out of scope of WSS, therefore we need say nothing about it.

 
> To summarize my position:
> a) the transform is NOT needed when all potentially 
> overlapping XML sig/enc
> is decribed in one security header.
> b) the transform MAY be needed when some potential exists for 
> overlapping
> XML sig/enc:

> b.1) purely at the application level (out of scope),

agreed

> b.2) between two security headers (in scope),

lets look at this in detail below

> b.3) between a security header and application level (in scope).

I don't understand the distinction between b.3 and b.1. Either enc/sig headers appear as children of a sec header (where the data under the enc or sig may be anywhere in the header or body) or enc & sig are being used in some other way. I argue that the first case is in scope, the second is out of scope. period. there is no third case I can see.

Let us consider b.2.

First note that the decrypt transform is a one trick pony. You have to specifically be doing sign & encrypt. The transform tells you that before you verify, you must decrypt. It does nothing for encrypt & sign, s-e-s, e-s-e, e-e-s, etc. Also as far as I can see the data encrypted and the data signed must be exactly the same node set, not merely overlapping. So already we are dealing with a limited special case, not a general solution.

Ok, I am guessing the case you are talking about is that for some reason a security header addressed to role A specifies that the data has been signed and a security header addressed to role B specifies that the data has been encrypted. If the role B is processed first, it will work, but if role A is processed first the signature will not verify. Since we do not know and can not control the order, we have a problem.

Note that the decryption transform does not actually solve the problem of determining the order. It is just a message to A that it must decrypt the data before verifying the signature. 

Unfortunately, there are a bunch of problems with this "solution."

1. If A decrypts the data, replacing the cyphertext with cleartext, then when B goes to decrypt, it will report an error, since the encrypted data is no longer present.

2. If B gets the message first, it will decrypt the data and then when A runs the transform it will get the error.

3. A and B must both know the secret key. This is not too bad if they are the same node, but is clearly bad practice if they are distinct nodes.

4. If the sender(s) know that A & B will be processed at the same node, it would seem that the sig and enc could go in the same header. If the sender(s) know that two nodes are involved, then they must know specifically that it is ok for the cleartext to pass from B to A.

I guess 1 & 2 could be dealt with by having a convention that a) when the decryption transform is run the cyphertext is not replaced by the cleartext (the cleartext is only used to verify the sig) and b) that if the decryption transform finds the decryption already done, it just skips that step. {This might cause a problem in case of a superencryption.) But then half of the time the decryption will be done twice. Also this does not seem to be specified by the W3C XML ENC WG, so presumably is not standard behavior for a library routine.

On balance, it seems to me that at best you are proposing an imperfect partial solution to a particular, not very common case. And remember we have truck sized holes that we probably can not deal with at all. For example, if the headers for one role are encrypted for another role, if the role to do the decryption is never reached, if the node implementing a role does not posses the necessary secret keys to perform the specified decryptions, etc.

I think we would be better off avoiding the complexity of handling the decryption transform (and specifying all its interactions with the rest of our machinery) than the tiny incremental benefits of supporting it in WSS.

To repeat what I said before, I see no bar to applications or other infrastructure using the transform in other contexts, just not in the security header.

Hal