RE: [wss] Determining the Order of Decryption and Signature Validation

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

Can't you put the EncryptedData in the header and use the
CipherReference inside that EncryptedData to refer to the actual
encrypted bytes wherever they are in the message?

Thanks,
Thomas.

-----Original Message-----
From: Hal Lockhart [mailto:hlockhar@bea.com] 
Sent: Monday, April 21, 2003 12:20 PM
To: wss@lists.oasis-open.org
Subject: [wss] Determining the Order of Decryption and Signature
Validation

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