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] Issue PR013: Need EncryptedSupportingTokens assertion


I was going by Tony Nadalin's suggestion that the spec doesn't prohibit this. I don't see anything in 4.2.1 that says we can't use this assertion for wss headers. Maybe I missed it. If that is truly the case, then I guess we would need another assertion. I don't know if it would require a SupportingTokens assertion though, would it? I should be able to use the recipient's token to encrypt the initiator's token in an asymmetric binding.
 
Tony G.


From: Symon Chang [mailto:sychang@bea.com]
Sent: Tuesday, February 13, 2007 2:56 PM
To: Tony Gullotta; ws-sx@lists.oasis-open.org
Subject: RE: [ws-sx] Issue PR013: Need EncryptedSupportingTokens assertion

Tony,

 

EncryptedParts is used for the non-security element in the header. Per section 4.2.1 of the spec, we can have the policy assertion like the following:

 

            <wsp:Policy>

                        <sp:EncryptedParts>

                                    <sp:Header Namespace="http://schemas.xmlsoap.org/ws/2004/08/addressing"/>

                                    <sp:Body/>

                        </sp:EncryptedParts>

            </wsp:Policy>

 

But we cannot have the policy assertion like this:

 

            <wsp:Policy>

                        <sp:EncryptedParts>

                                    <sp:Header Namespace="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"/>

                        </sp:EncryptedParts>

            </wsp:Policy>

Or:

 

            <wsp:Policy>

                        <sp:EncryptedParts>

                                    <sp:Header Name="Security/UsernameToken" Namespace="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd"/>

                        </sp:EncryptedParts>

            </wsp:Policy>

 

 

In other words, EncryptedParts assertion is not for security header. That is why we have SignedSupportingTokens, EndorsingSupportingTokens, SignedEncrypptedSupportingTokens, EndorsingEncryptedSupportingTokens, … assertions in the first place. The issue is: why EncryptedSupportingTokens is missing in current WS-SP spec? We need the EncryptedSupportingTokens to support a very basic WSS 1.0 function, i.e. to encrypt the plain text password.

 

Best regards,

 

 

Symon Chang 

 


From: Tony Gullotta [mailto:tony.gullotta@soa.com]
Sent: Wednesday, January 31, 2007 8:02 AM
To: ws-sx@lists.oasis-open.org
Subject: RE: [ws-sx] Issue PR013: Need EncryptedSupportingTokens assertion

 

In today's call during the discussion of PR013 we were discussing encrypting a password of a username token (or the whole token) without the need for a signature. Couldn't the policy look something like this:

 

AsymmetricBindingAssertion

Initiator token: UsernameToken

Recipient token: X509Token

No timestamp

 

EncryptedParts

UsernameToken

 

Wouldn't this work? It wouldn't require a signature would it?

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.


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