RE: Schema Centric Canonicalization algorithm

Hi Bob, 
 
Regarding canonicalizing esoteric node sets, such as nodes set with just
a single attribute: I am at a loss to suggest as to how best to attempt
to remedy c14n and exc-14n to correct for this; I assume you're much
more adept in that area than I. However, were those my specifications to
edit I would pretty strongly feel that that careful, specific attention
should at least be drawn therein to this issue, since in these
situations information is clearly lost during the canonicalization
process (that is, the namespace identities) and this directly leads to a
situation where contrary to the nature of signatures one can sign one
node set yet successfully verify against another totally different one.
This to me seems a security issue clearly worthy of note, even if we at
this point can't be particularly sanguine about the times in which
someone might actually attempt this. IMHO, it's not a matter of simply
'operating best', but a genuine issue of security (albeit pragmatically
probably a minor one) that should be documented.

<jb>

I am writing to ask whether you have had a chance to consider the email
I sent on this issue.  I expressed concern over the 'security hole'
language your group has used w.r.t. to canonicalizing so-called esoteric
node-sets.

 

Firstly, canonicalization is just a method for writing node-sets.  It
can only introduce a security problem if it is used in a security
context, so any notes about security need to be addressed relative to
XML DSig.

 

Secondly, if you are going to assert that there is a security hole in
'something' because attributes nodes are canonicalized without their
corresponding namespace nodes, then it should be a security hole any
time some of the nodes that lend meaning to other nodes are missing.  As
such, every canonicalization method including the one you are specifying
has the possibility of introducing a security hole into an application
as soon as it allows any form of document subsetting.

 

The group's work on this more general problem is readily available
because the XML DSig email archive is public; unless there is something
dreadfully wrong with W3C archiving, the term 'document closure' should
yield ample results.

 

In brief, it is our view that there is no 'security hole' in the XML
DSig Recommendation because it is the XPath expression author's
responsibility to write expressions that do not exclude nodes that must
be signed.  Please see Section 8 and particularly the first sentence of
8.1.1 in the XML DSig recommendation. 

 

As such, it would seem that a change of language is appropriate.  You
should also be careful to note that an infinitude of threat models
remain with your method because information dependencies in XML are in
no way constrained, so the deletion of any node could theoretically
affect the meaning of signed data.  Checking this sort of thing is an
application problem and beyond the scope of core validation.

 

John Boyer, Ph.D.

Senior Product Architect

PureEdge Solutions Inc.

</jb>

Received on Tuesday, 12 March 2002 18:24:00 UTC