[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [wss] WSS-Core-03-1103
|
6. Line 150: Another non-goal is the negation or exchange of security policy information.
Should be "negotiation" Don't want anyone negating my security policies J. Rob Philpott -----Original Message-----
I've not made it through the complete spec yet, but since we have the Monday deadline and I may not get back to this for a few days, I thought I'd send along my issues/comments through section 6.1.1.
Issues with WSS-Core-03-1103: 1. I have a general issue with the use of the "utility" namespace for defining elements and attributes used in wsse. It has not been explicitly stated anywhere that I am aware of that the WS-Security TC is responsible for defining this namespace and its associated schema. WS-Security cannot just presume the existence of the utility namespace schema. a. If we ARE going to define this namespace and schema in our TC, this needs to be explicit. HOWEVER, in this case I do not believe we should use the generic Web Services namespace tag of "wsu". Since it is the WS-Security TC defining it, it is NOT a general "Web Services" utility schema. It is a "WS-Security Utility namespace". The tag should thus be something such as "wssu" for "WS-Security Utility". b. If we ARE defining this namespace, then our specifications should FULLY define all elements and attributes that are defined in the current utility schema. Some wsu elements are defined in WSS-Core-03-1103 (e.g. in section 10.3 on Timestamps), but most others are not. c. If there is an expectation that "utility" is to be a truly general Web Services Utility namespace, then it may need to be defined by another TC with input from other Web Services-oriented bodies. But then, again, WSS won't be able to presume its existence at this time. 2. [Section 4.2 and elsewhere] I do not see any value in using "wsu:Id" when the base XML schema ID Type is available. This is especially true since "wsu:Id" is simply defined in utility as just being of type "xsd:ID". I believe it can only lead to confusion (and minor additional processing overhead). I recommend removing the use of wsu:Id in vavor of the base xsd:ID.
Editorial comments on WSS-Core-03-1103:
1. General: All references in the text to external documents and standards (e.g. XML DSig, our Bindings documents) should include cross-references to the corresponding reference item in section 16. 2. Line 109: [nit] need a space between SOAP and extensions 3. Lines 112-113: [nit] the spec isn't a basis for constructing security models such as PKI and Kerberos. It is a basis securing Web services within such security models. 4. Line 115: add a sentence stating something like "The token formats and semantics for using them with WS-Security are defined in the associated "Bindings" (profiles?) documents" and then include cross references. Also include the bindings cross references in section 16. 5. Line 148: [nit] "der ivation" extra space. 6. Line 150: Another non-goal is the negation or exchange of security policy information. 7. Line 166: [nit] "note that different elements... are from different namespaces" - suggest wording such as "note that elements used in this specification are from a variety of namespaces" 8. Lines 167-168: Need to use OASIS-based URL's (this is already on the issues list) 9. Line 195-197: Recommend generalizing the statement since we have to deal with more than 2 threats - Perhaps "When securing SOAP messages, various security threats need to be considered. This includes, but is not limited to: 1) the message could be..." (discussed on 11/5 con-call) 10.Line 218: [nit] "verifiable by, appropriate roles" - remove the comma. 11.Line 222: [nit] "although in this specification does not" - delete "in" 12.Line 241: [nit] need space between "SHOULD" and "reject" 13.Line 241: [nit] "reject a message with signature determined to" - add "a" between "with" and "signature" 14.Line 294: "Lines (006) to (009)" should be "Lines (005) to (009)". 15.Line 295: [nit] "Note that here that the" - delete 2nd "that" 16.Line 299: [nit] I think the parenthetical comment is unnecessary. 17.Line 299: "The signature uses the XML Signature specification" - append "identified by the ds namespace declaration in Line (002)" 18.Line 302: "Lines (011) to (018) describe the digital signature" - actually, these lines describe what information is being signed and how - it doesn't describe the actual signature. Also [nit] there shouldn't be a line break between Line 303 and 304 since 304-307 are part of the Lines (011) to (018) description. 19.Line 316: [nit] "elements such a signature references" should either be "elements such as signature references" or "elements such as a signature reference" 20.Line 330: [nit] "messag e" - delete the space. 21.Line 354: "arrtibute" - should be "attribute" 22.Line 405: [nit] "/ wsse:" should be "/wsse:" - delete the space. 23.Line 407: [nit] "may omit an role" - should be "may omit a role" 24.Line 426: change "can" to "MAY" 25.Line 433: "two additional optional elements" - delete "additional" 26.Line 434: "<wsse:UsernameToken>:" change to "<wsse:UsernameToken> element:" 27.Line 435: Change "they are included" to "they MUST be included"
Rob Philpott RSA Security Inc. The Most Trusted Name in e-Security Tel: 781-515-7115 Mobile: 617-510-0893 Fax: 781-515-7020 mailto:rphilpott@rsasecurity.com
-----Original Message-----
Here is an updated draft of WSS-Core with the following changes:
Proposed text to close item #20 Proposed text to close item #25 Proposed text to close item #26 Proposed text to close item #27 Clarified lines 733-735 with Ron's proposed text
(See attached file: WSS-Core-03-1103.pdf)
Anthony Nadalin | work 512.436.9568 | cell 512.289.4122 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC