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

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

Ok, thanks. Frankly, I had trouble understanding the spec.

My conclusions still stand.

Hal

> -----Original Message-----
> From: DeMartini, Thomas [mailto:Thomas.DeMartini@CONTENTGUARD.COM]
> Sent: Thursday, November 11, 2004 8:12 PM
> To: Hal Lockhart; Michael McIntosh
> Cc: Anthony Nadalin; wss@lists.oasis-open.org
> Subject: RE: [wss] Re: Issue 84 - Use of Decryption Transform
> 
> 
> ] 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
> 
> There is no requirement for the node sets to be the same.
> 
> ] 2. If B gets the message first, it will decrypt the data 
> and then when
> A
> ] runs the transform it will get the error.
> 
> The transform does not produce an error if there is nothing 
> to decrypt.
> 
> ] I guess [this] could be dealt with by having a convention 
> 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.
> 
> This is actually the standard behaviour (see above).
> 
> &Thomas.
> 
> ] -----Original Message-----
> ] From: Hal Lockhart [mailto:hlockhar@bea.com]
> ] Sent: Thursday, November 11, 2004 2:19 PM
> ] To: Michael McIntosh
> ] Cc: Anthony Nadalin; wss@lists.oasis-open.org
> ] Subject: RE: [wss] Re: Issue 84 - Use of Decryption Transform
> ] 
> ] 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
> ] 
> ] 
> ] 
> ] To unsubscribe from this mailing list (and be removed from 
> the roster
> of
> ] the OASIS TC), go to http://www.oasis-
> ] open.org/apps/org/workgroup/wss/members/leave_workgroup.php.
> 
>