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

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

Yes, I see it now. I really thought you had solved the problem. The problem
is not in core-12, which we could fix, but in XML ENcryption itself.

Basically, CypherReference is a mechanism to say "The cyphertext is over
there." What we need is a mechanism to say "Put the cleartext over there."

So I am still looking for ideas.

Hal

> -----Original Message-----
> From: DeMartini, Thomas [mailto:Thomas.DeMartini@CONTENTGUARD.COM]
> Sent: Tuesday, April 22, 2003 10:44 AM
> To: DeMartini, Thomas; Hal Lockhart; wss@lists.oasis-open.org
> Subject: RE: [wss] Determining the Order of Decryption and Signature
> Validation
>
>
> Never mind that: according to 9.4 and 9.4.1 of the WSS: Soap Message
> Security-12, it should instead look like the example in section 9.1.
>
> Thanks,
> Thomas.
>
> -----Original Message-----
> From: DeMartini, Thomas
> Sent: Monday, April 21, 2003 12:50 PM
> To: Hal Lockhart; wss@lists.oasis-open.org
> Subject: RE: [wss] Determining the Order of Decryption and Signature
> Validation
>
> 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
>
>
>