Re: [ws-sx] Encryption with a key known to both parties

[Rich Levinson <rich.levinson@oracle.com>]

Hi again Ruchith,

One other equivalent approach might be instead of using the SupportingTokens
element, you could use 
/sp:AsymmetricBinding/wsp:Policy/sp:InitiatorEncryptionToken
and sp:RecipientEncryptionToken elements, each of which would contain an
identical /wsp:Policy/sp:IssuedToken element as described in prev email 
below.
In addition, w this approach you could remove the sp:EncryptedParts element
since it should be automatic with this designation to tie in to the 
message level
input and output policies in the examples doc section 2.2.2

    Thanks,
    Rich

Rich Levinson wrote:
> Hi Ruchith,
>
> Let me take a crack at this referencing the WS-SecurityPolicy Examples
> document that is currently under review in the ws-sx TC:
>
>    
> http://www.oasis-open.org/committees/download.php/26176/ws-sp-usecases-examples-draft-17-07.doc 
>
>
> In section 2.2.2 of that documented is a use case called "(WSS1.0) Mutual
> Authentication with X.509 Certificates, Sign, Encrypt", which I think 
> fairly
> closely matches the use case you are referring to, with one exception, 
> that
> I will try to explain.
>
> First of all the use case #4 from the interop doc you ref should be 
> considered
> an "AsymmetricBinding" because the protection is primarily from the 
> initiator
> and recipient X.509 certificates which are used to sign the Body in 
> both the
> request and response. In addition, the example 2.2.2 shows that the 
> initiator
> should include the X.509 cert (line 1373 (P008)), but the recipient 
> should not
> (line 1383 (P017)), which also matches the interop use case #4.
>
> Use case 2.2.2 also in its input and output policies (lines 1415 (P047) -
> 1439 (P070)) matches the use case #4 by requiring the Body to be
> encrypted (lines 1422(P054), 1435(P066)).
>
> The only thing that is not explicitly covered is that there is an out 
> of band
> mutually agreed upon session key 
> (<xenc:KeyName>SessionKey</xenc:Keyname>)
> in the use case #4.
>
> Because this is a non-standard key and reference mechanism there is
> no WS-SP Token Type to refer to it. However, one might consider
> it an "IssuedToken" where the "Issuer" is whatever mutually agreed
> upon entity produced this token. In this case you might consider
> adding a SupportingTokens element to the Policy after the
> end of the AsymmetricBinding element between lines 1399(P038)
> and 1400 (P039) such as:
>
> <sp:SupportingTokens>
>    <wsp:Policy>
>       <sp:IssuedToken>
>          <sp:Issuer>SomeMutuallyAgreedURL</sp:Issuer>
>          <sp:RequireExternalReference/>
>       </sp:IssuedToken>
>       <sp:EncryptedParts>
>          <sp:Body/>
>       </sp:EncryptedParts>
>    </wsp:Policy>
>  </sp:SupportingTokens>
>
> I believe the RequireExternalReference can be taken to mean
> that the token used to encrypt the Body is going to be identified
> by some reference mechanism (the mutually agreed on key name).
> In the above example the Issuer element would be primarily used
> so that both parties understand the context to interpret the
> external reference.
>
> Hopefully this is helpful.
>
>    Thanks,
>    Rich Levinson
>
>
>
> Ruchith Fernando wrote:
>> Hi Folks,
>>
>> Is it possible to express "Scenario #4 Session Key" (the client and the
>> service uses a random symmetric key that has been previously agreed)
>> described in this [1] document with WS-SecurityPolicy?
>>
>> I guess we should use SymmetricBinding but how can we express the
>> Protection/EncryptionToken?
>>
>> Thanks,
>> Ruchith
>>
>> 1.
>> http://svn.apache.org/repos/asf/webservices/wss4j/trunk/specs/wss-interop2-draft-06.pdf 
>>
>>
>>   
>
> ---------------------------------------------------------------------
> 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_workgroups.php