Determining the Order of Decryption and Signature Validation

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

In a previous message:

http://lists.oasis-open.org/archives/wss/200304/msg00015.html

I identified an inconsistancy between different parts of the core spec
relating to how a Receiver can determine the proper order to perform
decryption and signature validation. It appears to me that there we have two
choices:

1. The order of processing can be determined completely by the order of
elements in the message. The use of the Decryption Transform is prohibited.

2. If a Decryption Transform is present, it must be used to determine the
order of processing. Otherwise, the order of elements is used to determine
the order of processing.

To repeat what I said in my earlier message, this is not a security threat.
The only consequences of incorrect order of processing is that signature
validation will fail whan it should succeed. It also does not effect the
ability to decrypt the data, although the question whether the data is
authentic is another matter. Thus an attacker (or a buggy intermediary) can
achieve nothing other than denial of service by reordering message elements.

Although the spec currently seems to mostly specify choice #2, everyone I
have talked to seems to feel that choice #1 would be preferable, if it can
be achieved. The main reason is that if we chose #1, receivers will have to
inspect every Signature to see if there are any Decryption Transforms
present, which defeats the ability to process the message in one pass. There
is also the complextity of supporting the transform.

In order to make #1 possible, three things are required.

1. Any sender generating elements that are both signed and encrypted must be
able to order the elements so as to indicate the correct processing order.

2. Any intermediary encrypting a portion of a message which overlaps with
any existing encrypted or signed data in the message, must be able to order
the elements so as to indicate that the decryption must precede the other
operations, whether adding to an existing security header or creating a new
security header (addressed to a different role).

3. Any intermediary signing a portion of a message which overlaps with any
existing encrypted data in the message, must be able to order the elements
so as to indicate that the signature verification must precede the
encryption, whether adding to an existing security header or creating a new
security header (addressed to a different role).

It seems to me that this is not possible using the current specification.

First let us be specific about what elements would be used to determine
encryption and signature order. It seems that the order of security tokens
will not do, because they may not be present at all or may be used by
multiple operations.

It would seem that the order of the EncryptedData and Signature elements
should indicate the order of processing. But that will not always work,
because the EncryptedData must appear where the cleartext was, which may be
in the Body and the Signature must appear in the header. Interop scenario #3
solves this problem by putting the EncryptedKey before Signature in the
header, but this will not always work.

For example, suppose we are using a symmetric key, say with Kerberos. If we
use it for both signature and encryption, I think we are ok, because I
believe the hash must be over the cleartext, so the hash can be encrypted.

However, suppose one party signs the body using a PK and then another party
encrypts the data with a symmetric key contained in a Kerberos ticket, for
example. How does the second party indicate that the data should be
decrypted first?

I haven't worked through all the possible combinations implied by the
various kinds of KeyInfo, STR's and so forth. Can anyone see a set of rules
which will let specify order without the need for the Decryption
Transformation?

Hal