RE: [ws-sx] Issue 33: Identity security header components that are encrypted when using (A)Symmetric binding

["Martin Gudgin" <mgudgin@microsoft.com>]

Prateek, TC,

Here is data for Issue 33. 

The following statements apply if the element listed appears as a child
of the wsse:Security header;

Signing

1. 	wsu:Timestamp is signed by the message signature.
2. 	wsu:Timestamp is signed by any endorsing signature in the case
of a transport binding.
3. 	wsse11:SignatureConfirmation is signed by the message signature.
4. 	ds:Signature of the message signature is signed by the signature
of an endorsing token.
5. 	ds:Signature of an endorsing token is never signed.
6. 	xenc:EncryptedKey is never signed.
7. 	xenc:EncryptedData is never signed.
8.	xenc:ReferenceList is never signed.
9.	Security Tokens ( e.g. wsse:UsernameToken,
wsse:BinarySecurityToken, wsc:SecurityContextToken, wsc:DerivedKeyToken
saml:Assertion ) are signed by the main signature if [Token Protection]
is set to 'true' or the tokens are present in the header because they
are Signed or SignedEndorsing support tokens.
10.	Security Tokens ( e.g. wsse:UsernameToken,
wsse:BinarySecurityToken, wsc:SecurityContextToken, wsc:DerivedKeyToken
saml:Assertion ) that are present in the header because they are
Endorsing and SignedEndorsing supporting tokens are signed by the
corresponding endorsing signature if [Token Protection] is set to
'true'.

Encrypting

11.	ds:Signature of the message signature is encrypted if
[SignatureProtection] is set to 'true'.
12.	wsse11:SignatureConfirmation is encrypted if
[SignatureProtection] is set to 'true'.
13.	wsse:UsernameToken should be encrypted if transport security is
NOT being used.
14.	ds:Signature of an endorsing token is never encrypted.
15.	xenc:EncryptedKey is never encrypted.
16.	xenc:EncryptedData is never encrypted.
17.	xenc:ReferenceList is never encrypted.

The following assumptions are made;

1.	No sp:SignedElements assertions are present in the policy that
would cause any of the above elements to be signed.
2.	No sp:EncryptedElements assertions are present in the policy
that would cause any of the above elements to be encrypted.

Let me know if the above makes sense.

Gudge

> -----Original Message-----
> From: Martin Gudgin [mailto:mgudgin@microsoft.com] 
> Sent: 19 April 2006 06:33
> To: Prateek Mishra
> Cc: ws-sx@lists.oasis-open.org; Paul Cotton; Marc Goodner
> Subject: RE: [ws-sx] Issue 33: Identity security header 
> components that are encrypted when using (A)Symmetric binding
> 
> Prateek, 
> 
> I'm sorry it has taken me so long to respond to this.
> 
> I've reviewed the thread and I am now in the process of collating all
> the information regarding signed and/or encrypted elements 
> appearing in
> the security header. Realistically, I am unlikely to have a
> comprehensive proposal until the end of next week. 
> 
> Regards
> 
> Gudge
> 
> 
> > -----Original Message-----
> > From: Prateek Mishra [mailto:prateek.mishra@oracle.com] 
> > Sent: 22 March 2006 14:29
> > To: Martin Gudgin
> > Cc: ws-sx@lists.oasis-open.org; Paul Cotton
> > Subject: Re: [ws-sx] Issue 33: Identity security header 
> > components that are encrypted when using (A)Symmetric binding
> > 
> > <PM> Comments below </PM>
> > 
> > >Paul kindly pointed me to the right thread, so I'm replying here so
> > >maybe we can keep the threads together. Apart from this 
> paragraph and
> > >the text of your/Marc's mail below the content of this mail 
> > is identical
> > >to my previous one.
> > >
> > >I think we discussed on one of the calls, that more things 
> > were signed
> > >than encrypted in the security header. However, certain things are
> > >encrypted, so perhaps we should rename the issue;
> > >
> > >"Identify security header components that are signed and/or 
> > encrypted"
> > >
> > >  
> > >
> > <PM> Agreed, this is a more comprehensive way to approach 
> > this question. 
> > Given a security policy based
> > on asymmetric/symmetric binding
> > it is hard to authoritatively figure out which headers are 
> > signed and/or 
> > encrypted. I am spending some time on this with
> > our engineers and I believe it will lead to an 
> interoperability issue.
> > </PM>
> > 
> > >Is that what you would like to clarify? Or was it just encrypted
> > >elements? Or just signed elements?
> > >
> > >  
> > >
> > >A quick look at Appendix C turns up, for the symmetric 
> > binding at least;
> > >
> > >SignedSupportingTokens
> > >SignedEndorsingSupportingTokens 
> > >[Signature Token] in the case where [Token Protection] is 
> > set to true.
> > >
> > >as being signed and;
> > >
> > >Message signature in the case where [Encrypt Signature] is true
> > >
> > >as being encrypted. 
> > >
> > >I guess I'm wondering whether it is worth stating a list of
> > >signed/encrypted elements at the binding level given that 
> > the presence
> > >of those elements depends on various property values and 
> in some case
> > >the signing and/or encrypting depends on property values too.
> > >
> > >  
> > >
> > <PM> How about a table that captures your comments above? We 
> > would need 
> > to fill it out with some more details.
> > 
> > For example, are [Signed] Supporting Tokens always encrypted?
> > 
> > Do the rules apply  to both requests and responses?
> > </PM>
> > 
> > 
> > 
>