[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]