• reorganization by audience - implementors or app developers.
• put in a lot of "why" before each best practice.

Pratik Datta wrote:

Sean,

I am not trying to cover any policy related issues here.

But it is kind of a policy issue, right? This is similar to WS Security Policy where there are constraints that are required to be satisfied. One of those constraints is to specify which parts of the document must be signed. So a validating (and signing) implementation must ensure those requirements are satisfied. Am I off?

The main issue, as you said, is just to see what was signed.

I now think they are related but a little different. "See what is signed" is more applicable to something processing and acting on the actual data that has been signed (and doesn't necessarily care what parts of the document were signed), whereas ensuring that certain elements are signed is more of a lower-level security related issue where the user isn't really involved (as you say below it is more of a programmatic issue). Anyway, I think they are both subject to the same sort of attacks when using arbitrary transforms. So the resulting best practice should cover both issues :)

I would like to know what kind of hooks can be put in the implementation code to cache and return data.

One idea is to get the bytes just before digesting and return that as an array of bytes.  However this approach is only useful for visual comparison, and can't be used for programmatic comparison - how would you produce the other array of bytes to compare with?  Also this approach is susceptible to wrapping attacks.

The other approach that I can think of (and this is what the Oracle implementation uses) is to run all the transforms except the last C14N transform, which may be implicit - the output of this should be nodeset. Then one can use the DOM3 method  isSameNode() to compare each node of the expected nodeset with the nodeset that is being signed. The expected nodeset should be a subset of the nodeset being signed. The restriction with approach is that there should not be any sequences of  transforms that converts from xml to binary and then back to xml, because in that case signed nodeset belongs to a different document, and will not match with the expected nodeset.

So maybe another best practice would be to advise that implementations have APIs to return this data (pre-digested and pre-c14n data).

--Sean