[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: WS-SP 1.2 questions regarding precedence for conflicting policy, other misc
Attempting to re-post via mailing list after web form post didn't seem to make it... Name: Gary McAfee Title: Software Engineer Organization: IBM Regarding Specification: WS-SecurityPolicy 1.2 It isn't clear to me from the specification what has precedence in several situations were there appears to be conflicting policy, or whether the policy should be rejected. I think there are several broad categorizations: 1. Whether tokens should be included in a message when their token inclusion value appears to conflict with other sections of the specification which indicate whether a token should be present in the message. For example, a token inclusion value could indicate a token MUST NOT be included in the message, but if the token is represented by a SignedSupportingToken or a SignedEndorsingSupportingToken in a Transport binding, the specification seems to indicate at least in the example in Appendix C, that the tokens need to be included, and no mention is made of the token's token inclusion value. 2. Whether Timestamps should be included when there appears to be a conflict between the [Timestamp] property and the apparent requirements of the supporting token assertions or the Transport binding. For example, if the [Timestamp] property were false and an EndorsingSupportingToken or a SignedEndorsingSupportingToken assertion was included in an endpoint policy including a Transport binding. The section on Supporting Tokens says the supporting tokens 'should' sign the Timestamp element. It's not clear if the Timestamp element should be added to satisfy the supporting token assertion (I suspect not since the [Timestamp] property says a Timestamp MUST NOT be present if the value is set to false). If a Timestamp is not present in a message using a Transport binding, then this introduces a one-to-many mapping between the message and the various types of supporting token assertions. For example, in a message using a Transport binding without a Timestamp element, the message would look the same whether the endpoint policy contained a SupportingTokens, SignedSupportingTokens, or SignedEndorsingSupportingToken assertion. 3. The very beginning of the "Supporting Tokens" section (first paragraph, second sentence) says "The Security Binding will require one to create a signature using the token identified in the Security Binding policy". It's not clear whether a policy that contains nothing specifically that will generate a message signature is still valid. I'm restricting this discussion to Symmetric and Asymmetric bindings since Transport bindings have their elements implicitly signed. For example, if the security binding specified not to have a timestamp, and there was no message policy (and therefore no SignedParts or SignedElements), and no SignedSupportingToken or SignedEndorsingSupportingToken assertions, it appears we could have a message without a message signature. Furthermore, this kind of situation makes it much more difficult to map an incoming message to a policy since deriving the binding used to generate such a message from the message itself is difficult or results in a one-to-many mapping between the message and various policies that could map to such an ambiguously constructed message. 4. The examples in the appendix for the Symmetric and Asymmetric cases show the UsernameToken as being signed and encrypted, yet the example policy that goes along with them shows nothing that would cause the UsernameToken to be signed and encrypted. Could the reason for this be clarified?
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]