Re: [wss] Proposed text changes relating to EncryptedHeader

[NISHIMURA Toshihiro <nishimura.toshi@jp.fujitsu.com>]

Hal,

# I'm sorry for replying to the old message.
# http://lists.oasis-open.org/archives/wss/200412/msg00037.html

Current draft (dated 16 May 2005) has adopted your proposal as follows:

Lines 1640-1645
| 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.

Lines 1653-1655
| 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.

Lines 1700-1703
| 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.

I wonder why Lines 1653-1655 uses "SHOULD".

I see Lines 1640-1645 says that
  S11:actor MUST be copied from the <wsse:Security> element to the
  <wsse11:EncryptedHeader> element.
And Lines 1700-1703 says that
  the decrypted header element and <wsse11:EncryptedHeader> element
  MUST have the same S11:actor value.
Based on these two, I can conclude that the <wsse:Security> element
and the header element to be encrypted (which is same with decrypted
header element) MUST have the same S11:actor value. 
(And because WSS prohibits two security headers being targeted to the
same Role/Actor, encrypting <wsse:Security> with
<wsse11:EncryptedHeader> is not possible.)

Am I misunderstanding something?

Toshi
---
NISHIMURA Toshihiro (FAMILY Given)
nishimura.toshi@jp.fujitsu.com
STRATEGY AND TECHNOLOGY DIV., SOFTWARE GROUP, FUJITSU LIMITED


At Mon, 13 Dec 2004 15:21:17 -0500,
Hal Lockhart wrote:
> 
> 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
> 
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php.
> 
>