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

Re: Best Practices comments

From: Pratik Datta <pratik.datta@oracle.com>
Date: Mon, 02 Jun 2008 17:28:32 -0700
Message-ID: <48449030.6050701@oracle.com>
To: Sean Mullan <Sean.Mullan@sun.com>
CC: XMLSec <public-xmlsec-maintwg@w3.org>

Sean,

I am not trying to cover any policy related issues here. The main issue, 
as you said, is just to see what was signed.

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.



Pratik

Sean Mullan wrote:
>
> Hi Pratik,
>
> Here's a couple of initial comments. Will send more as a I get time...
>
> --Sean
>
> Pratik Datta wrote:
>> Sean,
>>
>> Here are my proposed edits to make things clearer.  (It doesn't 
>> include any reorganization, we could discuss that in the call)
>>
>> --------------------------------------
>> Section 2.1
>> Complexity is the enemy of security [BradHill] <#ref-BradHill>. Avoid 
>> using complicated features of XML Signature, especially complicated 
>> transforms, since it makes it hard for the receiver to know what was 
>> actually signed
>
> Although Brad did mention that as one of the issues, it was only one 
> of the issues listed in his paper (the sentence above makes it sound 
> like that was the main focus). I think it needs to be reworded, or 
> alternatively, we could reference Brad's paper as each relevant issue 
> is discussed.
>
>> Consider the following XML where the Approval needs to be signed
>> <Doc>
>>  <Approval>...</Approval>
>> </Doc>
>>
>> The receiver needs to verify that  a) the Approval element was 
>> signed, b) signing key is valid, and c) the signature itself is valid.
>
> I wonder if the issue could be phrased  a little differently. As I 
> understand it, the main issue in this section is that the receiver 
> needs to be able to see (and subsequently determine if it trusts) 
> exactly what was signed, i.e. 
> http://www.w3.org/TR/2008/PER-xmldsig-core-20080326/#sec-See . Using 
> simple local ID references and one or two secure transforms makes it 
> easier to compute and display this information. Using more 
> complicated, arbitrary transforms makes it harder to do that (because 
> the data that was signed is not visible in the document and instead 
> requires processing complicated, and sometimes potentially insecure 
> transforms which may be subject to attacks that can change the data) 
> and also requires hooks in the implementation to cache and return that 
> data.
>
> There's also sometimes a requirement on signers to ensure that they 
> sign certain parts of the document, to abide by certain profiles, etc. 
> But I think that's more of a policy related issue. I'm not sure if you 
> are also trying to cover that issue. When I read "verify that the 
> Approval element was signed", it seemed like a policy related issue to 
> me but I think it's just the way it is worded.
>
> --Sean
>
Received on Tuesday, 3 June 2008 00:29:54 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 June 2008 00:29:55 GMT