[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: RE: [ws-sx] Issue 117: Element or Content Encryption on SignedEncryptedSupportingTokens Assertion
After some internal discussion, we are now in favor of making the rule that all encryption is #Element, except for the SOAP <Body>. This is what I believe both Chris and Gudge are supporting. Hal > -----Original Message----- > From: Hal Lockhart > Sent: Tuesday, October 31, 2006 12:14 PM > To: Martin Gudgin; Marc Goodner; ws-sx@lists.oasis-open.org > Subject: RE: RE: [ws-sx] Issue 117: Element or Content Encryption on > SignedEncryptedSupportingTokens Assertion > > The argument for encrypting the content of a token is that an > unacceptable token type can be rejected without performing the > decryption first. This provides some protection against one class of DoS > attacks. > > However, we are mostly interested in seeing this clarified, as opposed > to insisting on a particular choice. > > Hal > > > -----Original Message----- > > From: Martin Gudgin [mailto:mgudgin@microsoft.com] > > Sent: Monday, October 30, 2006 8:08 PM > > To: Martin Gudgin; Marc Goodner; Hal Lockhart; > ws-sx@lists.oasis-open.org > > Subject: RE: RE: [ws-sx] Issue 117: Element or Content Encryption on > > SignedEncryptedSupportingTokens Assertion > > > > Further to my previous, terse, missive; > > > > In the WSS 1.0 interop[1] (and subsequent WSS 1.1 interop[2]) the > > UsernameToken was encrypted using #Element. This further reinforces my > > belief that #Element is what we want here. > > > > Cheers > > > > Gudge > > > > [1] http://www.oasis- > > open.org/apps/org/workgroup/wss/download.php/2362/wss-interop1-draft- > > 05.doc > > [2] http://www.oasis- > > > open.org/apps/org/workgroup/wss/download.php/12997/wss-11-interop-draft- > > 01.doc > > > > -----Original Message----- > > From: Martin Gudgin [mailto:mgudgin@microsoft.com] > > Sent: Tuesday, October 24, 2006 8:41 PM > > To: Marc Goodner; Hal Lockhart; ws-sx@lists.oasis-open.org > > Subject: RE: [ws-sx] Issue 117: Element or Content Encryption on > > SignedEncryptedSupportingTokens Assertion > > > > Hal, > > > > I don't understand why I'd want to use #content when encrypting > tokens. I > > would have thought #element more likely. > > > > Gudge > > > > -----Original Message----- > > From: Marc Goodner [mailto:mgoodner@microsoft.com] > > Sent: Monday, October 23, 2006 10:20 AM > > To: Hal Lockhart; ws-sx@lists.oasis-open.org > > Subject: [ws-sx] Issue 117: Element or Content Encryption on > > SignedEncryptedSupportingTokens Assertion > > > > Issue 117. > > > > -----Original Message----- > > From: Hal Lockhart [mailto:hlockhar@bea.com] > > Sent: Thursday, October 19, 2006 10:33 AM > > To: ws-sx@lists.oasis-open.org > > Cc: Marc Goodner > > Subject: NEW Issue: Element or Content Encryption on > > SignedEncryptedSupportingTokens Assertion > > > > PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL > > THE ISSUE IS ASSIGNED A NUMBER. > > > > The issues coordinators will notify the list when that has occurred. > > > > Protocol: ws-sp > > > > WS-SecurityPolicy 1.2, Editors Draft 01, 01 September 2006 > > ws-securitypolicy-1.2-spec-ed-10 > > > > > <http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.php/20579/w > > s-securitypolicy-1.2-spec-ed-01-r10.doc> > > > > Artifact: spec > > > > Type: design > > > > Title: Element or Content Encryption on > SignedEncryptedSupportingTokens > > Assertion > > > > Description: > > > > Section 8.5 SignedEncryptedSupportingTokens does not define whether to > > use Element Encryption or Content Encryption to encrypt the token. > This > > will be difficult to interop with different implementations and create > > some confusion to the user. Section 8.6 > > EndorsingEncryptedSupportingTokens Assertions and Section 8.7 > > SignedEndorsing EncryptedSupportingToken Assertions have the same > issue. > > > > Related issues: none > > > > Proposed Resolution: > > > > Add one sentence to Sec. 8.5, Sec. 8.6, and Sec. 8.7: "Content > > Encryption should be used for encrypting the supporting tokens.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]