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

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

My apologies to everyone for being so muddleheaded about this. Thomas is
quite right, CypherReference allows us to put the EncryptedData element in
the Security header while leaving the Cyphertext in the body. On decryption
the Cleartext will be inserted in place of the Cypertext.

It appears to me that if we wish to use the simple scheme of using a
relative URI to refer to a Id attribute, we must specify an EncryptedData
Type attribute value of "Content". Otherwise (that is if we use "Element")
the Id will be encrypted along with everything else and the Receiver won't
be able to find it.

Can some XML encryption experts confirm that this is how it works?

Given all that, we need to formulate some rules about the semantics of the
order of various encryption and signature elements. I think the most basic
question is should the use of CypherReference be mandated at all times or
only when necessary to produce the proper ordering of elements?

My current thinking is that mandating the use of CypherReference at all
times will make the implementation of both the Sender and the Receiver
simpler. It would also allow us to say that the ordering semantics depend
only on the relative position of the Signature and EncryptedData elements,
that the ordering of EncryptedKey, Token or STR elements have no
significance in terms of processing order. (They would still be required to
come first to enable one pass processing.) This approach also has the
advantage of insuring that all the "Security Goop" appears in the Security
header and not scattered through the Body.

Of course, the base 64 Cyphertext will appear in line. That means any entity
processing the message prior to encryption must not barf on something that
looks like:

<soap:Body Id="body" ... >
lkadjujfpwjJ6HPIogugfLJL2HOuhgJSHPPJhP3IJPIJpjpiJ490
jhjygykhhfgp8GFYUIIOPPP58KpERTRYT8ger4hUI56ibnyokHFDr
...
</soap:Body>

which is not legal XML. But that is implied by the use of CypherReference
and is never an issue if decryption precedes other processing. (I assume
that XML Sig can deal with this in the case of encrypt then sign. The spec
states that that the digital content being signed does not have to be XML.)

What does everyone think of this approach? Do you agree it simplifies
implementation (or at least makes it no harder)?

Hal

> -----Original Message-----
> From: Hal Lockhart [mailto:hlockhar@bea.com]
> Sent: Wednesday, April 23, 2003 12:17 PM
> To: DeMartini, Thomas; wss@lists.oasis-open.org
> Subject: RE: [wss] Determining the Order of Decryption and Signature
> Validation
>
>
> 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
> >
> >
> >
>
>