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

Re: Best Practices comments

From: Sean Mullan <Sean.Mullan@Sun.COM>
Date: Mon, 02 Jun 2008 16:01:37 -0400
To: Pratik Datta <pratik.datta@oracle.com>
Cc: XMLSec <public-xmlsec-maintwg@w3.org>
Message-id: <484451A1.2030500@sun.com>

Hi Pratik,

Here's a couple of initial comments. Will send more as a I get time...


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 

> 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.

Received on Monday, 2 June 2008 20:02:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:58:44 UTC