W3C home > Mailing lists > Public > public-xmlsec-maintwg@w3.org > June 2008

Re: Best Practices comments

From: Sean Mullan <Sean.Mullan@Sun.COM>
Date: Tue, 03 Jun 2008 15:18:17 -0400
To: Pratik Datta <pratik.datta@oracle.com>
Cc: XMLSec <public-xmlsec-maintwg@w3.org>
Message-id: <484598F9.90507@sun.com>

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
Received on Tuesday, 3 June 2008 19:19:08 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 June 2008 19:19:09 GMT