Proposed text changes relating to EncryptedHeader

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

I propose changing lines 1460-1476 from:

----------
In certain cases, it is desirable that an entire SOAP header block including the top-level element, descendants and all attributes need to be encrypted. In such a case, the original header block is replaced with a <wsse11:EncryptedHeader> element. The <wsse11:EncryptedHeader> element contains the <xenc:EncryptedData> produced from encrypting the header block. A wsu:Id attribute MAY be added to the <wsse11:EncryptedHeader> element for referencing. If the referencing <wsse:Security> header block defines a value for the <S12:MustUnderstand> or <S11:MustUnderstand> attribute, that attribute and associated value SHOULD be copied to the <wsse11:EncryptedHeader> element. If the referencing <wsse:Security> header block defines a value for the S12:Role or S11:Actor attribute, that attribute and associated value SHOULD be copied to the <wsse11:EncryptedHeader> element.

Any header block can be replaced with a corresponding <wsse11:EncryptedHeader> header block. This includes <wsse:Security> header blocks. In addition, <wsse11:EncryptedHeader> header blocks can be super-encrypted and replaced by other <wsse11:EncryptedHeader> header blocks (for wrapping/tunneling scenarios). Any <wsse:Security> header that encrypts a header block targeted to a particular actor SHOULD be targeted to that same actor.
----------

to:

==========
When it is required that an entire SOAP header block including the top-level element and its attributes be encrypted, the original header block SHOULD be replaced with a <wsse11:EncryptedHeader> element. The <wsse11:EncryptedHeader> element MUST contain the <xenc:EncryptedData> produced by encrypting the header block. A wsu:Id attribute MAY be added to the <wsse11:EncryptedHeader> element for referencing. If the referencing <wsse:Security> header block defines a value for the <S12:MustUnderstand> or <S11:MustUnderstand> attribute, that attribute and associated value MUST be copied to the <wsse11:EncryptedHeader> element. If the referencing <wsse:Security> header block defines a value for the S12:Role or S11:Actor attribute, that attribute and associated value MUST be copied to the <wsse11:EncryptedHeader> element.

Any header block can be replaced with a corresponding <wsse11:EncryptedHeader> header block. This includes <wsse:Security> header blocks. (In this case, obviously if the encryption operation is specified in the same security header or in a security header targeted at a node which is reached after the node targeted by the <wsse11:EncryptedHeader> element, the decryption will not occur.) 

In addition, <wsse11:EncryptedHeader> header blocks can be super-encrypted and replaced by other <wsse11:EncryptedHeader> header blocks (for wrapping/tunneling scenarios). Any <wsse:Security> header that encrypts a header block targeted to a particular actor SHOULD be targeted to that same actor, unless it is a security header.
==========

Rationale:

Improved normative language. 

Propose making copying of MustUnderstand and Actor mandatory (use of EncryptedHeader at all is still optional.) 

Clarify logic around encrypting of security header. Note: WSS prohibits two security headers being targeted to the same Role/Actor. (Actually I see no good reason for encrypting an entire security header, but I decided not to propose prohibiting it.)

************

I propose changing lines 1511-1519 from:

------------
2. The processor MUST, after decrypting the encrypted header block, process the decrypted header block according to the SOAP processing guidelines. The receiver MUST raise a fault if any content required to adequately process the header block remains encrypted or if the decrypted SOAP header is not understood and the value of the S12:mustUnderstand or S11:mustUnderstand attribute on the decrypted header block is true. Note that this is the value of the S12:mustUnderstand or S11:mustUnderstand on the resulting decrypted header element, NOT the value of the S12:mustUnderstand or S11:mustUnderstand on the <wsse11:EncryptedHeader> element.
------------

to:

============
2. The processor MUST, after decrypting the encrypted header block, process the decrypted header block according to the SOAP processing guidelines. The receiver MUST raise a fault if any content required to adequately process the header block remains encrypted or if the decrypted SOAP header is not understood and the value of the S12:mustUnderstand or S11:mustUnderstand attribute on the decrypted header block is true. Note that in order to comply with SOAP processing rules in this case, the processor must roll back any persistent effects of processing the security header, such as storing a received token.

3. If the value of the S12:mustUnderstand, S11:mustUnderstand, S12:Role or S11:Actor attributes on the resulting decrypted header element, differ from the value of the corresponding attribute on the <wsse11:EncryptedHeader> element, the processor MUST raise a fault. Note that in this case the SOAP processing rules do not require a roll back of persistent effects.
============

Rationale:

Make the obligations of the SOAP processing model explicit.

Consistent with the proposal to make the copying of attributes mandatory.

Hal