Best Practices comments

I found this draft a bit difficult to read and a bit all over the place. 
It might be more useful to take a step back and reorganize it a bit. 
Some of the advice is more for implementors, and some of the advice is 
for signers, and other advice is for application specific usages like 
WSS. I also think there's a lot of "don't do this", but not enough of 
"why you should not do this". More examples would also be useful. A 
section at the end with several complete signatures abiding with 
most/all of the best practices would also be useful.

I could try to suggest a different structure, if others also think it is 
worthwhile. Some specific comments follow.

Section 2.1.1

I found this section a bit difficult to follow. I think more of Brad's 
advice/rationale could be listed.

First paragraph: "Avoid using complicated features of XML Signature, 
especially complicated transforms, since it makes it hard for the 
receiver to know what was actually signed."

That's part of the problem (and may not really be a problem if you are 
using an implementation that can cache and display exactly what was 
signed). The other problems are the potential DOS and other attacks with 
certain transforms, and in general the added complexity and more code 
involved (which inevitably has more bugs) and which makes it harder to 
test all the scenarios.

The first bullet says "First an XPath transform ...". This reads as if 
we are advising that XPath be used instead of ID references. This should 
be reworded. It may be better to suggest avoiding XPath, but if 
necessary list some best practices (such as #2 and #3) when using it.

Best Practice #1: an example would be useful to explain this. Also some 
more details about why this is a problem.

This section only discusses limiting transforms when signing. An 
implementation may also want to reject signatures that use certain 
transforms or don't abide by certain practices.

BP #2 and #3 seem related. I would combine them into one BP about XPath 
transforms. A link to the McIntosh wrapping attack paper would also be 
useful here. Also, BP #3 and BP #4 are related so maybe this should be 
moved to section 2.1.2.

Unreadable sentence: "XPath Filter 2 transforms are much to understand 
...". I think it should be "much easier". If so, I don't understand this 
advice. The XPath transform is a SHOULD as well. Is the advice to avoid 
any transform that is not a MUST? If so, that might be good advice.

Section 2.1.2

BP #4 seems inconsistent with the advice given in section 2.1.1. That 
section said it is ok to sign portions of the document as long as you 
use ID references or XPath transforms with some restrictions. This BP 
says to sign all parts (does that mean the whole document?) unless 
impractical.

Section 2.2

I think we need to add more details as to why validating keys first is 
better.

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

More details would be useful here. What is an external reference and why 
is it bad? (I would move BP #7 before BP #6). Does this mean they are ok 
in Reference URIs? It might be better to say something like "since a 
RetrievalMethod is very similar to a Reference (has a URI and 
Transforms), all of the issues that have been discussed with respect to 
complex Transforms are also applicable. Also, a RetrievalMethod can 
reference itself, which may lead to an infinite loop and a DOS attack ..."

BP #7: I think more details on the DOS threats with external URIs would 
be useful.

--Sean

Received on Wednesday, 28 May 2008 18:54:35 UTC