RE: RE: [ws-sx] Issue 117: Element or Content Encryption on SignedEncryptedSupportingTokens Assertion

["Hal Lockhart" <hlockhar@bea.com>]

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.