RE: [wss] Proposed text changes relating to EncryptedHeader

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

Well this was outside of the changes I proposed, (except for the phrase "unless it is a security header") but I believe lines 1653-1655 are referring to the encrypted header before it is wrapped. But perhaps it is simply obsoleted by the other changes.

Hal

> -----Original Message-----
> From: NISHIMURA Toshihiro [mailto:nishimura.toshi@jp.fujitsu.com]
> Sent: Wednesday, May 25, 2005 6:33 AM
> To: Hal Lockhart
> Cc: wss@lists.oasis-open.org
> Subject: Re: [wss] Proposed text changes relating to EncryptedHeader
> 
> 
> 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.
> > 
> > 
>