Some rework on my earlier input.

2.1.1 Limit transforms

When signing XML data  use
  - first an XPath transform to locate the elements to be signed.  If you are using an ID reference, don't use XPath
  - after that an "Enveloped" transform to exclude this signature in case of enveloped signatures
  - finally a C14N transform or a transform that includes C14N (e.g. an STRTransform in WSS includes C14N)

When signing binary data use
  - base64 decode transform or equivalent (e.g. an Attachment Content/Complete Transform in WSS SWA) to get the bytes in binary

Don't use a chain of transforms which cause the xml data to be converted to binary and then reparsed back into XML - such transforms are very hard to understand.

When using XPath transforms consider using a only a single RelativeLocationPath in the ancestor-or-self axis.
e.g.   ancestor-or-self:foo
will select all <foo> elements  all over the document.

It is usually not a good idea to create a complicated Xpath expression that signs some specific <foo> elements but not others as that may lead to wrapping attacks.  An attacker may insert/delete/modify some <foo> elements to get important data excluded from the signature.

XPath Filter 2 transforms are much to understand, but they are not a MUST, so some implementations do not support them.



2.2  Reduce opportunities for denial of Service attacks
  Best Practice 5 Avoid RetrievalMethod

 RetrievalMethods can have bad transforms, external references and infinite loops.

 Example of Retrieval methods with infinite loop : 

<RetrievalMethod Id="rm" URI="#rm"/>

Infinite loops can also happen with a circular chain of RetrievalMethods .



Best Practice 8: Take care with XSLT transforms.

It is easy to have a DoS attack with a single XSLT transform, just by having many levels of nested for loops

Example of time consuming XSLT coperation
<Transform Algorithm="http://www.w3.org/TR/1999/REC-xslt-19991116">
              <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
                <xsl:template match="/">
                  <xsl:for-each select="//. | //@*">
                    <xsl:for-each select="//. | //@*">
                      <xsl:for-each select="//. | //@*">
                        <foo/>
                      <xsl:for-each>
                    <xsl:for-each>
                  <xsl:for-each>
              </xsl:stylesheet>
            <Transform>

In this example each "for-each" loops over all the elements and attributes in the document (including all children, grandchildren, great grand children etc). So if there are a 100 such elements and attributes, and we nest it three times, then element "</foo>" will be emitted 100*100*100 times

Pratik


Konrad Lanz wrote:
Hi Sean,

Yes, we can link this to DSS ... we had experienced and discussed the
issues there as well ...

http://lists.oasis-open.org/archives/dss/200504/msg00048.html

Konrad

Sean Mullan schrieb:
  
I think it might be useful to have a best practice on signing "legacy 
XML", or XML without namespace information. If you create an enveloping 
signature over XML without namespace information, it may inherit the XML 
Signature namespace of the Object element, which is not the intended 
behavior. There are two potential workarounds that I have been advising 
users to workaround this :

1) Insert an xmlns="" namespace definition in the legacy XML. However, 
this is not always practical.

2) Insulate it from the XML Signature namespace by defining a namespace 
prefix on the XML Signature (ex: "ds").

I would be curious as to whether others have had similar issues and what 
solution they recommend. The 2nd point above is probably a good practice 
in general.

Also, a nit on the best practices doc:

- section 2.1 typo: s/expecially/especially

--Sean

Frederick Hirsch wrote:
  
    
What I propose we do as a WG to progress the Best Practices draft is the 
following:

1. WG members please review the current Editors Draft [1], which 
reflects some suggestions on the last teleconference.

2. WG members propose text to be added or changed in the current Editors 
draft , by sending an email to the public WG mail list (please include 
[BestPractices] in email Subject line)

3. WG discuss and agree to changes.

What I would like to accomplish on our next call is to get to a baseline 
draft that the WG agrees reflects WG consensus. To do this WG members 
must review the current draft, make concrete proposals for changes and 
additions on the email list in advance of the meeting, agree as a WG to 
those changes and then review and agree that a subsequent draft reflects 
those changes.

Please indicate any suggestions or concerns with this process to the 
public list, please review the draft, and please send proposals to the 
list in advance of 6 May.

If there is any WG member who wishes to join as an editor please let 
Thomas and myself know so we can discuss.

Thanks

regards, Frederick

Frederick Hirsch, Nokia
Chair, OASIS Strategy Committee

[1] http://www.w3.org/2007/xmlsec/Drafts/xmldsig-bestpractices/