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.

 

Regards,

 

Paula Austel

IBM T.J. Watson Research

Hawthorne, NY 10530



 

WSS SOAP Message Security 

Comments on Working Draft 17 dated 27 Aug 2003

 

 

Non-repudiation

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

 

Terminology

 

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..."