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

["DeMartini, Thomas" <Thomas.DeMartini@CONTENTGUARD.COM>]

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