Re: [wss] Issue 84 - Order of encryption and signature - Proposed Changes

[Jerry Schwarz <jerry.schwarz@oracle.com>]

I have a couple of specific thoughts below. I've elided proposed changes on 
which I have nothing to say.

A generic issue. There are lots of uses of the phrase "the <wsse:Security> 
header block"  or similar that imply there is only one such header 
block.  We are supposed to be able to have more than one.

At 11:49 AM 6/2/2003, Hal Lockhart wrote:
>The intention is the following:
>
>o order of decryption and signature verification is determined by order of
>elements in the security header(s).
>o Decryption transform is not used
>o Tokens and STRs should be in the order for most convenient use
>o Schemes requiring alternate processing, such as forwarding cyphertext
>after having inspected the cleartext cannot be implied by the message format
>and must be the subject of out of band agreement.
>
>Specific changes to core 13:
>
>---
>Lines 842-843
>
>Current: For processing efficiency it is RECOMMENDED to have the signature
>added and then the security token pre-pended so that a processor can read
>and cache the token before it is used.
>
>New: Any Security Token elements or <wsse:SecurityTokenReference> elements
>required to validate the signature SHOULD placed in order to allow the most

                                           ^^
                                           be

>convenient processing in a single pass. In most cases, this will mean
>placing them immediately before the <ds:Signature> element.


If I later add another signature using the same elements to supply key's, 
etc.  Should I place the signature after these auxilliary elements?

>---
>Lines 953-957
>
>Current: When a sender or an intermediary encrypts portion(s) of a SOAP
>message using XML Encryption they MUST prepend a sub-element to the
><wsse:Security> header block. Furthermore, the encrypting party MUST prepend
>the sub-element into the <wsse:Security> header block for the targeted
>recipient that is expected to decrypt these encrypted portions.
>
>New: When a sender encrypts portion(s) of a SOAP message using XML
>Encryption they MUST place a sub-element so that a recipient decrypting the
>data can determine the correct order of processing Signature and encryption
>elements by processing each in the order they appear in the message. In most
>cases, this will mean prepending the sub-element to the existing content of
>the <wsse:Security> header block. Furthermore, the encrypting party MUST
>insert the sub-element into the <wsse:Security> header block for the
>targeted recipient that is expected to decrypt these encrypted portions.
>---

I think an implication here is that an encrypted element can be addressed 
to only one party.  Is that intentional?