Multiple Encryption

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

I have been continuing to try to formulate the rules for processing
encryption and signature headers so as to guarentee the correct order of
operations. The main issue that seems unclear to me at the moment is the
presence of multiple headers of the same type, either within the same
Security element or in distinct ones. More precisely I am concerned with the
presence of multiple encryption headers (specifically, ReferenceList or
EncryptedKey elements) since, as far as I can tell, the processing of any
number of Signature blocks is straightforward.

One obvious use of multiple encryption headers is the super-encryption of
data. This is most likely to occur, where independant processing elements
encrypt overlaping (or identical) portions of the data without regard for
the actions of other processing elements. Given the loosely coupled and
composable nature of web services, this seems to be a likely scenario and
has been in fact mentioned in a number of documents.

In such a case, the processing of encryption headers by intermediaries or
endpoints seems straightfoward. A processing element consumes the encryption
headers in the Security element labeled with the role it is assuming,
ignoring all others. It processes the headers in order, replacing cyphertext
with cleartext as indicated. If the element is an intermediary, it passes
the resulting data stream on to the next node.

Another possible use of multiple EncryptedKey elements in different security
headers is to enable multiple roles, possessing distinct private asymmetric
keys, to get access to the same data, encrypted with the same symmetric key.
This might allow a virus checker to scan encrypted content before it is
passed to an application or allow an Authorization processor to inspect an
encrypted request in order to make an access control decision. I have not
heard this requirement mentioned before, but this technique is common in
email environments, when sending email to multiple receipients (although not
always within the same message).

In this scenario, the processing required of an intermediary is quite
different. The intermediary, should perform the decryptions indicated in the
Security header labeled with its role, passing the result to its local
application. However, the message forwarded to the next node should contain
the original cyphertext. The receiver will use its own private key to
decypher it.

Unfortunately, at the moment, I do not see any way to distinguish these
cases by inspecting the message. It seems to me we have two choices:

1. Declare the "multiple receipient" usecase to be unsupported, defining
processing rules which will prevent its use.

2. Create some mechanism to indicate that "multiple receipient" is being
done in a particular message and mandate special processing rules in that
case.

(I have rejected the idea of a prior agreement as being inconsistent with
the general design philosophy of WSS.)

Personally I prefer #1, as it will make life much simpler. I have not worked
through all the possible combinations and would be glad not to have to.

Does anyone feel strongly that we must support a "multiple receipient"
capability?

Does anyone see any other cases in which multiple encryption headers might
be used? In particular, cases which require processing that is incompatable
with the super-encryption case?

Hal