OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wss-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Comments on Working Draft 17

Please accept these combined comments from a group within the IBM Research division. Please contact me if you have any questions.
Paula Austel
IBM T.J. Watson Research
Hawthorne, NY 10530

WSS SOAP Message Security
Comments on Working Draft 17 dated 27 Aug 2003


This document should clarify whether non-repudiation is in scope. While digital signatures may form the basis for non-repudiation, additional application specific services are required for a complete solution. Non-repudiation has legal consequences that depend on the semantics of the application, the awareness to this semantic and legal consequences by the signer, and the level of confidence one may have in the verification of the signature (Did the verifier use the right certificate? Is the certificate valid for this application? Is there non-readable text that has been signed? Is this a purely automated verification or human-assisted? What are dispute handling procedures? etc.) We therefore recommend that it be explicitly stated that non-repudiation is not in the scope of this document.

Specify non-repudiation as a non-goal in section 1.1.2
Remove definitions of terms that are not used in the document. Specific examples of this are "Proof-of-Possesion" and "Trust Domain".

Clarify in the definition of the term "Signature" that its use within this document is intended to address message integrity and authentication. This can be done using either symmetric or asymmetric mechanisms.

Throughout the document use the term "Signature" consistently instead of "Digital Signature".

Security Considerations

This document is an extensible framework intended to be used with a variety of security mechanisms and token formats which are not fully specified in the document. Section 13 Security Considerations includes a list of concerns and potential techniques for addressing them. Any complete set of security considerations would be the result of a thorough security analysis of a specific implementation and the security mechanisms and tokens formats used therein. Therefore, the security considerations included in this section are not, and cannot be made to be, comprehensive. The inclusion of this incomplete set of security considerations may unintentionally lead some readers to believe that addressing each of the included items by using one of the referenced techniques will result in a secure implementation.

We recommend moving the username token specific security considerations to the Username Token Profile and the X.509 certificate token considerations to the X.509 Certificate Token Profile. We further recommend removing the other specific security considerations for this section. Finally, we recommend reiterating the text from Section 1.1 Goals and Requirements in this section: "This specification is intended to provide a flexible set of mechanisms .... As with every security protocol, significant efforts must be applied to ensure that security..."

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]