Re: Schema Centric Canonicalization algorithm

On Tuesday 12 March 2002 20:50, Bob Atkinson wrote:
>  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.

I'm willing to document the issue (proposed text will follow). With xmldsig 
and xenc we've given great flexibility to applications, particularly via 
the transforms mechanism so calling out issues that one needs to be aware 
of is important.

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

I'm glad that we generally agree that these "esoteric scenarios" are not 
compelling scenarios. I'm satisfied if your approach is to throw an error 
(at first I misunderstood and though you considered them important to 
support) and if we continue to support them but point out that such 
nodesets must be constructed with care, as we already do in other cases.

So I undersand your specification better, I have two quick questions.

1. The error you throw in this case result from section 3.4.3 [1]?
2. I'm not sure how you disagree with John with respect to "serializing" a 
noteset. Your input is an infoset (either as parsed or converted from an 
XPath nodeset) and you serialize. You do serialize it in a specific way, 
and one of those ways is that you throw fatal errors given characteristics 
of the input Infoset. Is this characteristic the one that leads you to 
state you are doing more than serializing infoset items? Also, is it 
possible to simply describe input which fails to trigger fatal errors? For 
instance, will SCC14N always work over all well-formed XML -- that  might 
be schema valid, or might not?


If info is an element or attribute information item whose [namespace name] 
property is not no value, then let a be that namespace declaration 
attribute in the [normalized namespace attributes] of some self-ancestor of 
info where the [normalized value] property of a is identical to the 
[namespace name] property of info (if no such a exists, a fatal error 
occurs. This can occur, for example, if all element information items in 
the infoset are omitted, but some attributes are retained.). The 
[normalized prefix] property of info then exists and is the [local name] 
property of a.

> Cheers,
> 	Bob
> -----Original Message-----
> From: John Boyer []
> Sent: Tuesday, March 12, 2002 3:23 PM
> To: Bob Atkinson;
> Cc:;;
>;; 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>


Joseph Reagle     E0 D5 B2 05 B6 12 DA 65  BE 4D E3 C1 6A 66 25 4E

* This email is from an independent academic account and is
  not necessarily representative of my affiliations.

Received on Wednesday, 13 March 2002 14:37:18 UTC