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 

RSA Security Inc. 

The Most Trusted Name in
e-Security 

Tel: 781-515-7115 

Mobile: 617-510-0893 

Fax: 781-515-7020 

mailto: 

-----Original Message-----

From: Philpott, Robert 

Sent: Tuesday, November 05, 2002
12:56 PM

To: Web Services Security

Subject: RE: [wss]
WSS-Core-03-1103

 

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: 

 

 

-----Original Message-----

From: Anthony Nadalin [mailto:] 

Sent: Tuesday, November 05, 2002 12:17 AM

To: Web Services Security

Subject: [wss] WSS-Core-03-1103

 

 

 

 

 

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