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

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

Fulfilling my action item from last week; I think this information
belongs in an appendix, as it's really a collation of existing material.
I propose we add the following;

Appendix x - Signed and Encrypted Elements in the Security Header

This appendix lists the criteria for when various child elements of the
Security header are signed and/or encrypted at the message level
including whether they are signed by the message signature or a
supporting signature. It assumes that there are no sp:SignedElements and
no sp:EncryptedElements assertions in the policy. If such assertions are
present in the policy then additional child elements of the security
header might be signed and/or encrypted.

X.1 Elements signed by the message signature

1.	The wsu:Timestamp element.
2.	All wsse11:SignatureConfirmation elements.
3.	Security Tokens corresponding to [Initiator Signature Token],
[Recipient Signature Token], [Initiator Encryption Token], [Recipient
Encryption Token], [Signature Token] or [Encryption Token] when [Token
Protection] has a value of 'true'.
4.	Security Tokens corresponding to [Signed Supporting Tokens] or
[Signed Endorsing Supporting Tokens].

X.2 Elements signed by all endorsing signatures

1.	The ds:Signature element that forms the message signature
2.	The wsu:Timestamp element in the case of a transport binding

X.3 Elements signed by a specific endorsing signature

1.	Security Tokens corresponding to [Endorsing Supporting Tokens]
or [Signed Endorsing Supporting Tokens] when [Token Protection] has a
value of 'true'

X.4 Elements that are encrypted

1.	The ds:Signature element that forms the message signature when
[Signature Protection] has a value of 'true'
2.	All wsse11:SignatureConfirmation elements when [Signature
Protection] has a value of 'true'
3.	Any wsse:UsernameToken when a transport binding is NOT being
used.

Cheers

Gudge


> -----Original Message-----
> From: Martin Gudgin 
> Sent: 30 April 2006 15:58
> 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, 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>
> > > 
> > > 
> > > 
> >