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

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

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


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


Hi Ruchith,

Your question has been submitted as an official issue for the
ws-sx TC to consider and will be on the issues list as #160.
One possible outcome is to add it as an option to an example
or as a new example. Will let you know as to the outcome.

    Thanks,
    Rich

Ruchith Fernando wrote:
> Thanks Rich for the suggestion!
>
> I certainly can implement this with a custom URI value to indicate the 
> "known" key value with your approach. I'm wondering, for interop 
> purposes, whether this approach should be documented for other 
> implementations to follow as well?
>
> Regards,
> Ruchith
>
> Rich Levinson wrote:
>> 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
>>
>
>


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