[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]