RE: Schema Centric Canonicalization algorithm

Joseph:

 

Regarding esoteric node sets, a clear note of warning to applications and users should indeed be quite sufficient.

 

The error thrown in this case is indeed from §3.4.3, specifically from the paragraph that you identified.

 

My point about serializing was simply one of perception and focus, and wasn't a deep one. It was expressed that "canonicalization is just a method for writing node-sets". Well, for starters in SCC14N node-sets are rather incidental, as infosets are the focus. Further, an XPath node set still always carries around behind itself the full underlying tree against which the nodes in the set are actually interpreted; this tree and related derivative information is (often) lost in the transcription through a canonicalization algorithm such as c14n, exc-c14n, or scc14n. Thus, it has never really struck me at all to think about canonicalization as "just a method for writing node-sets". The issues I can see are related, but certainly not equivalent, and I don't see great utility in equating the two, even conceptually. That was all that I was alluding to; nothing profound.

 

It is certainly possible to enumerate and characterize the causes of the fatal errors in scc14n, though we haven't specifically done that yet. In particular, well-formed namespace-conformant schema-valid XML that validates against schemas in which all embedded languages can be appropriately understood per §3.4.2 will not so fatally terminate.

 

      Bob

 

-----Original Message-----
From: Joseph Reagle [mailto:reagle@mit.edu] 
Sent: Wednesday, March 13, 2002 11:37 AM
To: Bob Atkinson; John Boyer
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

 

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?

 

[1] 

http://www.uddi.org/pubs/SchemaCentricCanonicalization-20020213.htm#sec-Specification-Xform-ns-normalize

 

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

 

-- 

 

Regards,          http://www.mit.edu/~reagle/

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.