ISSUE-55 (Implementation language): Language should not focus on implementations but on specification use [Best Practices for XML Signature]

ISSUE-55 (Implementation language): Language should not focus on implementations but on specification use [Best Practices for XML Signature]

http://www.w3.org/2008/xmlsec/track/issues/55

Raised by: Frederick Hirsch
On product: Best Practices for XML Signature

Title - Language should not focus on implementations but on specification use

Description - 
Language in the best practices may be misinterpreted to judge implementations or to constrain them when there are reasons for the way they operate (eg. alternative means of mitigating risk, operating in trusted environment etc). Change wording to avoid misinterpretation

Target - Best practices, http://www.w3.org/2007/xmlsec/Drafts/xmldsig-bestpractices/

Proposal
Change best practices draft as follows

(1) Change the following text in 2.1 from
"XML signature implementations are often used in application server systems, where multiple incoming messages are being processed simultaneously. In this situation incoming messages should be assumed to be possibly hostile, and it is not acceptable for a single poison message to bring down an entire set of web applications and services.

An implementation that literally follows the XML signature spec and performs the reference validation before the signature validation is extremely susceptible to denial of service attacks. As will be seen below, certain kinds of transforms require an enormous amount of processing time, certain retrieval method constructs lead to infinite loops and certain external URI references can lead to security violations. An implementation should at first "authenticate" the signature, before running any of these dangerous operations."

to

"XML Signature  may be used in application server systems, where multiple incoming messages are being processed simultaneously. In this situation incoming messages should be assumed to be possibly hostile with the concern that a single poison message could bring down an entire set of web applications and services.

Implementation of the XML Signature specification should not always be literal. For example,  reference validation before signature validation is extremely susceptible to denial of service attacks in some scenarios. As will be seen below, certain kinds of transforms may require an enormous amount of processing time and certain external URI references can lead to possible security violations. One recommendation for implementing the XML Signature Recommendation is to first "authenticate" the signature, before running any of these dangerous operations."

(2) Section 2.1, paragraph starting "In step 1" change

"An implementation that must handle potentially hostile messages should choose to allow only very constrained RetrievalMethods - e.g. those that do not have any transforms, and only one level of indirection using a local URI."

to

"When implementing the XML Signature Recommendation in an environment with potentially hostile messages, it is recommended to  allow only very constrained RetrievalMethods - e.g. those that do not have any transforms, and only one level of indirection using a local URI."

(3) Change in paragraph 6 in 2.1

"The implementation should at first validate the public key."

to

"The public key should be verified before validating the signature value."

(4) Section 2.1.1 replace

"But as mentioned before the scope of this denial of service attack is greatly reduced if the implementation follows the above best practices, because it is unlikely that an authenticated user would include this kind of transform"

with

"The scope of this denial of service attack is greatly reduced when following the best practices described above, since  it is unlikely that an authenticated user would include this kind of transform."

(5) In section 2.1.1 replace

"To totally eliminate these kinds of attacks an implementation can choose to not support XSLT at all or provide a mechanism to allow the application to optionally disable support for it."

with

"An implementation of XML Signature may choose not to support XSLT, may provide interfaces to allow the application to optionally disable support for it, or may otherwise mitigate risks associated with XSLT."

(6) section 2.1.1 replace

"To totally eliminate this kind of attack an implementation can choose to not support XPath Filter transform at all or provide a mechanism to allow the application to optionally disable support for it."

with

"An implementation of XML Signature may choose not to support the XPath Filter Transform, may provide interfaces to allow the application to optionally disable support for it, or otherwise mitigate risks associated with it."

(7) In section 2.1.4 replace "Implementations should" with "When implementing XML Signature, it is recommended to" in paragraphs 3 and 4.

In paragraph 5, replace "Implementations that support XSLT transforms may further wish" with
"When implementing XML Signature with support for XSLT transforms, it can be useful"

(8) In section 2.2 replace

" For an application, it is completely meaningless to invoke a xmlsec library call to verify a signature, without knowing what the signature is really signing."

with

" When implementing XML Signature it is important to understand what is provided by a signature verification library, and whether additional steps are required to allow a user to see what is being verified."

(9) In section 2.2 replace

"There rules need to be modified slightly for WSSecurity, which adds some extra transforms - an STRTransform could be used in place of an C14N transform, and for SWA Attachment, Attachment Content/Complete transform could be used in place of base64"

with 

"These sample rules may need to be adjusted for the anticipated use.  When used with web services WS-Security, for example, consider the  STR Transform  in place of a C14N transform, and with SWA Attachment, Attachment Content/Complete transform could be used in place of a base64 transform."

(10) Section 2.3 replace
"An implementation should provide a mechanism to inspect a signature and return was signed. "

with

"When implementing XML Signature some environments may require a means to provide a means to be able to return what was signed when inspecting a signature."

(11) In 2.3.2 replace

" For this the implementation should run through all "

with 

"This should include all"

Replace "If there are multiple references in the signature, the implementation should compute a union of these nodesets and return them." 

with

"If there are multiple references in the signature,the result should be a union of these nodesets."

Received on Wednesday, 24 September 2008 20:17:31 UTC