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:]
> Sent: 22 March 2006 14:29
> To: Martin Gudgin
> Cc: ; 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>
>
>
>
