Issue 84 - Resolved

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

Summary of conclusion: The Decryption Transform does not have any practical
use in WSS and therefore should be prohibited.

To review:

Signatures can be combined and verified in any order without difficulty.
However, when data is encrypted more than once or is signed before or after
encryption the coresponding verification and/or decryptions must occur in
the proper order or the signature verifications or decryption will fail.

We have established that within a single security header order can always be
unambigiously specified by prepending the encryption and signature elements
to the existing header. Thus there is no need to support the Decryption
Transform in this case. It has been suggested that the Decryption Transform
is required in cases where distinct security headers specify overlapping
operations. This analysis addresses that question.

What is the Decryption Transform (DT)? It is actually quite a simple idea.
Recall that data being signed can be passed through one or more
transformations before the digest is calculated. This mechanism is used to
implement C14N. The DT simply says: before you sign this stuff, decrypt it.
In the absence of something like a SOAP header it provides a way to specify
decrypt-then-verify.

Analysis:

In general, ordering breaks into three cases: super-encrypt, encrypt & sign
and sign & encrypt. Obviously, the DT is irrelevant to the first two. Let us
consider sign & encrypt.

Suppose an entity wants to encrypt data that has been signed (presumably by
another entity, but that does not matter for our purposes.) It could prepend
to the existing header, but suppose it believes that the decryption and
verification will be performed by distinct SOAP Roles. For the sake of
example, let us assume 4 roles: S, E, V, D, each of which is capable of
performing the corresponding operation: sign, encrypt, verify and decrypt.
The roles may reside within 2, 3 or 4 SOAP nodes.

First suppose the DT is not used. The encryption element is put in the
header addressed to D and the signature element is put in the header
addressed to V. This presumes the configuration is like this:
           S-E-D-V or SE-D-V (or perhaps S-E-DV assuming the DV node can
sort out the order.)

However, what if the actual path is like: S-E-V-D or SE-V-D. In general SOAP
intermediaries are ignorant of routing. (Note the initial sender and
ultimate receiver perforce always know their identities.) Here is where it
is proposed that the DT might help. Suppose the E Role modifies the
signature to include the DT pointing to the decryption in a different
header. If the V Role gets the message first, it will begin processing the
signature, see the DT and perform the decryption first, removing the
encryption header. This does require the E Role to search all the other
headers to find any overlapping signatures, but this does not seem a serious
objection, since this already a tricky and rare case.

However, suppose this approach is taken and the path actually is S-E-D-V.
The D node gets the message and ignoring any signatures, does the decryption
and removes the entire security header addressed to Role D. Then when the V
Role tries to validate the signature, the DT will point to a non-existent
header. I orginally thought that this would force the D Role to always
search every header for possible signatures pointing to the decryption it
performed, and remove the DT. I thought this would be quite onerous, given
that it would have to be performed on every message with more than one
header, even if the DT was never used!

However, there is simpler approach. All we need to do is add a special rule
that says if you are verifying a signature and you come across a DT that
points to a non-existent encryption, assume it is already done and proceed
with the verification. (If your assumption is wrong, the verify will fail.)

All of this was an amusing exercise, but in fact quite useless! No Role can
do decryption unless it knows the key. The D and V Roles have no way to
route the messages to each other and get them back. Ignoring the fact that
in general sharing a long term secret among multiple nodes is a bad security
practice, if the V Role can do decryption, why bother to have the D Role at
all? I can see no sensible usecase where it is not necessary to simply
assume that the routing will have to allow the operations to be performed in
the correct order. If not, the verification will fail and the routing will
have to be corrected, the DT will not solve the problem.

Note that this actually applies to all three cases: super-encrypt, encrypt &
sign and sign & encrypt. Incorrect routing will cause either verification or
decryption to fail (although failed decryption might be harder to detect)
and there is nothing WSS can do about it.

Therefore my conclusion is that we might as well prohibit the use of the DT
in signatures in security headers, since they are never useful and require
work to support. Of course if applications want to send signed objects in
SOAP bodies or attachments, that is their business and outside of the scope
WSS.

Hal