[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: RE: [ws-sx] Issue 116: Is Appendix D Normative?
Hal, Thanks for doing the legwork on this. Your proposal looks good to me and I happily accept it. Cheers Gudge -----Original Message----- From: Hal Lockhart [mailto:hlockhar@bea.com] Sent: Tuesday, October 24, 2006 1:09 PM To: Hal Lockhart; Marc Goodner; ws-sx@lists.oasis-open.org Subject: RE: [ws-sx] Issue 116: Is Appendix D Normative? As promised, I have tried to determine the origin of all the rules in Appendix D, to try to settle the issue of whether the information is a summary of rules normatively specified elsewhere. I also looked at the discussion thread for Issue 33, which resulted in the creation of Appendix D. Issue 33, began when Prateek noted that one could infer from Appendix C (clearly marked as non-normative) certain information about what items should be encrypted. Prateek suggested that this information appear in section 7.3 & 7.4, which would of course have indicated it was normative. This was later expanded to include signatures as well as encryption and moved to Appendix D. Here is what I have found. Although it is easy to tell when you find a rule, it is much harder to say for sure no rule exists or that there are not other, contradictory rules elsewhere. So I hope someone will correct me if I have missed a reference. First I am confident that the WSS and WS-SecCon and WS-Trust do NOT tell you what you should encrypt or sign. Therefore I confined my attention to WS-SP. Here is what I found. Note once again that this is only the stuff you always have to sign or encrypt in the absence of SignedElements or EncryptedElements assertions. My notes are inside of {}. D.1 Elements signed by the message signature 1. The wsu:Timestamp element. {Section 6.2 says if the timestamp is present it must be signed or protected by the transport level. Perhaps the latter should be called out in a separate rule in the same way as D.2 #2.} 2. All wsse11:SignatureConfirmation elements. {I can't find anything. Specifically section 9 - WSS 1.1 Properties [Signature Confirmation] (lines 2288-2294) does not mention an integrity requirement the way section 6.2 does, even though this is the logical place for the rule.} 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'. {Section 6.5 mandates this} 4. Security Tokens corresponding to [Signed Supporting Tokens] or [Signed Endorsing Supporting Tokens]. {Section 8.2 & 8.5 mandate this.} D.2 Elements signed by all endorsing signatures 1. The ds:Signature element that forms the message signature. {Section 8.3 mandates this.} 2. The wsu:Timestamp element in the case of a transport binding. {Section 8.3 mentions this using a lowercase "should".} D.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' {Section 8.8 mandates this.} D.4 Elements that are encrypted 1. The ds:Signature element that forms the message signature when [Signature Protection] has a value of 'true'. {Section 6.4 mandates this.} 2. All wsse11:SignatureConfirmation elements when [Signature Protection] has a value of 'true'. {Section 6.4 mandates this.} 3. Any wsse:UsernameToken when a transport binding is NOT being used. {I can't find this anywhere. Section 6.7.1 #2. b. (Strict Layout Rules) says "A Username token (usually in encrypted form) MUST occur ..." I take this as a clear indication that a Username token will not ALWAYS be encrypted.} ----- My recommendations are: I. Amend Appendix D with references to the source. II. Add a rule for Timestamp protected by Transport. III. Amend the Signature Confirmation text in section 9 to indicate an integrity requirement. IV. Amend the part of 8.3 that mentions transport binding to be an uppercase MUST. V. Amend or eliminate rule D.4 #3 based on the outcome of Issue 115. Hal > -----Original Message----- > From: Hal Lockhart > Sent: Monday, October 16, 2006 11:18 AM > To: Marc Goodner; ws-sx@lists.oasis-open.org > Subject: RE: [ws-sx] Issue 116: Is Appendix D Normative? > > Ok, then where specifically does rule D.4 #3 come from? (for example) > > Hal > > > -----Original Message----- > > From: Marc Goodner [mailto:mgoodner@microsoft.com] > > Sent: Monday, October 16, 2006 10:55 AM > > To: Marc Goodner; Hal Lockhart; ws-sx@lists.oasis-open.org > > Subject: RE: [ws-sx] Issue 116: Is Appendix D Normative? > > > > I've looked into this and Appendix D was added to SP per issue 33. > > > > From Gudge's accepted proposal for that issue: > > "I think this information belongs in an appendix, as it's really a > > collation of existing material." > > > > So Appendix D is not normative and the material does exist elsewhere. > I > > believe 116 can be closed with no action. > > > > -----Original Message----- > > From: Marc Goodner [mailto:mgoodner@microsoft.com] > > Sent: Wednesday, October 11, 2006 6:33 AM > > To: Hal Lockhart; ws-sx@lists.oasis-open.org > > Subject: [ws-sx] Issue 116: Is Appendix D Normative? > > > > Issue 116 > > > > -----Original Message----- > > From: Hal Lockhart [mailto:hlockhar@bea.com] > > Sent: Tuesday, October 10, 2006 2:12 PM > > To: ws-sx@lists.oasis-open.org > > Cc: Marc Goodner > > Subject: [ws-sx] NEW Issue: Is Appendix D Normative? > > > > 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 > > > > > http://www.oasis-open.org/committees/download.php/20578/ws-securitypolic > > y-1.2-spec-ed-01-r10-diff.pdf > > > > Artifact: spec > > > > Type: > > > > editorial > > > > Title: > > > > Is Appendix D normative or is it just a summary of information found > > elsewhere in the spec as Appendix A is? > > > > Description: > > > > The last sentence of section 1 says "Section 11, all examples and all > > Appendices are non-normative." That suggests that Appendix D is a > > summary of normative information which is found elsewhere. However, I > > can not find any other source of the information in WS-SP. If Appendix > D > > is non-normative, then I question why it is in the document at all. > > > > Note that Appendix A explicitly says it is non-normative, suggesting > > that some Appendices may be. Appendix B could conceivably be > considered > > normative, it is hard to tell. Appendix C is examples, so it seems > safe > > to assume they are not normative, however it might be good to say > > explicitly that if Appendix C conflicts with section 6.7 then 6.7 > takes > > precedence. > > > > Related issues: > > > > My previous issue. > > > > Proposed Resolution: > > > > Clarify which Appendices are normative.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]