OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: RE: [wss] Proposed text changes relating to EncryptedHeader


Ok, so I guess the bottom line is that there are conceivable usecases where a node decrypts data to be used by another node. Although IMO opinion the situation is unlikely to occur in practice, I agree we should change or eliminate the text.

Hal

> -----Original Message-----
> From: NISHIMURA Toshihiro [mailto:nishimura.toshi@jp.fujitsu.com]
> Sent: Tuesday, May 31, 2005 12:16 AM
> To: wss@lists.oasis-open.org
> Subject: Re: [wss] Proposed text changes relating to EncryptedHeader
> 
> 
> Thank you, Hal,
> 
> # Line numbers are based on the draft dated 16 May 2005.
> 
> I noticed that Lines 1640-1645 says "If the referencing
> <wsse:Security> header block defines a value for the S12:Role or
> S11:Actor attribute". There are cases when the referencing
> <wsse:Security> header block does not define those attribute.
> 
> 
> One example came up to me.
> Sender sends a message with <Foo> header block to Receiver.
> There are 2 intermediaries (A and B) between Sender and Receiver and A
> encrypts the <Foo> header block and B decrypts it.
> 
> 1) Sender sends a message:
> <S11:Header>
>   <Foo S11:actor="Receiver" S11:mustUnderstand="1">..</Foo>
> </S11:Header>
> 
> 2) Intermediary-A encypts the <Foo> (results in an <EncryptedHeader>
> and a <Security> targetted to Intermediary-B):
> <S11:Header>
>   <wsse11:EncryptedHeader S11:actor="....." 
> S11:mustUnderstand="..">..</wsse11:EncryptedHeader>
>   <wsse:Security S11:actor="Intermediary-B" 
> S11:mustUnderstand="1">..</wsse:Security>
> </S11:Header>
> 
> 3) Intermediary-B dencypts the <EncryptedHeader> (results in 
> the original
> message):
> <S11:Header>
>   <Foo S11:actor="Receiver" S11:mustUnderstand="1">..</Foo>
> </S11:Header>
> 
> 4) Receiver process the <Foo> header block.
> 
> (Note that the <Foo> header block can be a <wsse:Security> 
> header block)
> 
> The target of <Security> produced by step 2 will be Intermediary-B
> because only Intermediary-B can process it (decrypt the
> <EncryptedHeader>).
> 
> What is the target of <EncryptedHeader> ?
> A) Based on Lines 1640-1645, it is copied from the referencing
> <Security> header: "Intermediary-B"
> B) Based on Lines 1700-1703, it must be same with the value of the
> resulting decrypted header: "Receiver"
> They are conflicting!!
> 
> 
> 
> At Fri, 27 May 2005 14:28:26 -0400,
> Hal Lockhart wrote:
> > 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
> <snipped> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all 
> your TCs in OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgr
> oups.php 
> 
> 


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]