RE: Schema Centric Canonicalization algorithm

Thanks, John, for your comments.

Though I didn't take pains to point it out, SCC14N in fact terminates
with a fatal error in these esoteric node sets, and so is not subject to
the hole.

Clearly (and perhaps regrettably) we disagree as to if or where this
concern should be documented, and perhaps other things (I do not think
at all of SCC14N as a "means to write a node set", for example). Your
comments notwithstanding, and in part in light of the above, I continue
to think this to be an issue worthy of explicit note in with respect to
canonicalization algorithms, not with respect to XML DSIG. It is to me
most clearly a hole, and should be documented as such. But then again,
for anything other than SCC14N, I have no direct say in the matter.

The thing that makes attribute nodes special, which is the thing that
leads to this particular problem, is that while the attribute node can
stand alone, it's XML expression (in either c14n, exc-c14n, or scc14n)
cannot: the node intrinsically caries the namespace binding within
itself, whereas this cannot be done in the XML expression. For this
reason, these particular node sets have problems distinguished from
other nodes sets; in particular, distinguished from the arbitrary node
deletions to which you refer. 

Cheers,

	Bob

-----Original Message-----
From: John Boyer [mailto:JBoyer@PureEdge.com] 
Sent: Tuesday, March 12, 2002 3:23 PM
To: Bob Atkinson; reagle@w3.org
Cc: uddi-security@yahoogroups.com; w3c-ietf-xmldsig@w3.org;
selim.aissi@intel.com; mhondo@us.ibm.com; Allen Brown; Ashok Malhotra
Subject: 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 20:50:30 UTC