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

[Anthony Nadalin <drsecure@us.ibm.com>]

So we don't have a consensus ? Just o be clear Hal, you say you always need a decryption transform and others are saying there are cases where you don't, right ? Is this on the list to talk about tomorrow ?

Anthony Nadalin | Work 512.838.0085 | Cell 512.289.4122
"Hal Lockhart" <hlockhar@bea.com>

"Hal Lockhart" <hlockhar@bea.com>

11/12/2004 09:06 AM

To	"DeMartini, Thomas" <Thomas.DeMartini@CONTENTGUARD.COM>, Michael McIntosh/Watson/IBM@IBMUS
cc	Anthony Nadalin/Austin/IBM@IBMUS, <wss@lists.oasis-open.org>
Subject	RE: [wss] Re: Issue 84 - Use of Decryption Transform

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.
>
>

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.