Re: verifying order of resources in a document

Mark, this actually is a critically important feature of processing XML. The
issue is specifically that XML as a markup language has no object
interconnection mechanisms that set order, precedence, or inter/Intra Object
Control Policy.

What this means is that any XML Stream that is interpreted, MUST be
interpreted in a top-down, first come-first processed model, and with the
Core XML spec this only makes sense for applications that need to process
digital information as though there was a piece of paper there.

But even that is potentially flaky, for instance if I set a browser to
display in Japanese and pump the standard XML stream into it. It displays
Kanji in top down and right to left. We read left to right and then top down
here in the States, so which instrument and which object is processed first.
Forget the legal issues here for a minute, and just tell me how the proof
models work for representing events in this XML stream that are language or
presentation engine independent.

As to the current vision, I have to ask "Is it the Browser that enforces
this?" -  So far it is it seems and the value of the digital instrument
based on this concept is totally leverages against the browser as the
presentation engine... Take the browser away and the model disintegrates
making XML no mo' bettah than ASN.1 for writing forms, algs, and
datastructures in.

Todd

----- Original Message -----
From: Mark Bartel <mbartel@thistle.ca>
To: 'John Boyer ' <jboyer@uwi.com>; <w3c-ietf-xmldsig@w3.org>
Sent: Thursday, July 29, 1999 9:39 AM
Subject: RE: verifying order of resources in a document


> John,
>
> My basic point is that the capabilities that you ask for (except for
> omitting subelements) can be built on top of the current specification.
The
> ordering issue isn't a security hole, it is something we have chosen not
to
> address in this layer.  Since most applications won't care about verifying
> order, I think this is an entirely appropriate choice.
>
> I must admit that I had misunderstood what you meant by omitting elements.
> You are suggesting that we provide some method of saying "sign this
element,
> except for these subelements".  It seems to me that this significantly
> confuses the meaning of "this element is signed", violates the basic web
> philosophy of modularity (2.8 in the requirements), and considerably
> complicates processing of signatures.  But perhaps that's just because in
my
> experience (forms, workflow, and pki applications) I don't see a need for
> it.
>
> Interesting that you mention workflow... as a workflow engine developer, I
> don't agree with your assessment of the difficulties.  If the user does
> anything too esoteric with their document format, they might have to add
> some special processing logic (a capability we've supported since version
1)
> but in most cases I expect we'll be able to do standard processing.
>
> Finally, I thought there was consensus that we were leaving the issue of
> verifying resource content to the application?  I believe this is the
proper
> course, for the reasons Don outlines in
> http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999JulSep/0071.html.
>
> -Mark Bartel
>
> -----Original Message-----
> From: John Boyer
> To: Mark Bartel; w3c-ietf-xmldsig@w3.org
> Sent: 7/28/99 3:29 PM
> Subject: RE: verifying order of resources in a document
>
> Hi Mark,
>
> <John>
> For starters, please see
> http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999AprJun/0032.htm
> l
>
> Replies within...
> </John>
>
> There has been an issue raised about a security hole related to the
> order of
> resources in a document.  It is true that the order of resources is not
> guaranteed by the specification, but I'm confused as to why this is an
> issue.  This is my understanding of the possibilities for asserting an
> order... please comment if I'm missing something here.
>
> <John>It is an issue because none of the suggestions you have below are
> addressed in the proposals currently under consideration.  The change
> I'm
> proposing is not large, but the problem is insofar as any security hole
> is a
> problem.</John>
>
> 1.  Have a DTD (of some sort) that orders the elements, and include it
> in
> the manifest.
>
> <John>If you are requiring that the DTD be applied to validate the
> document
> before committing to doing a signature, then you are proposing one of a
> number of variations on the types of solutions I'm claiming are needed.
> This is no different from requiring that the order of the resources
> listed
> in the manifest is the same order that the elements appear in the
> document.</John>
>
> 2.  Arrange the document so that one is signing an ancestor of the
> elements
> for which the order matters.  Obviously you can't do this if you don't
> have
> control of the document format.  However, if you don't have control of
> the
> document format, how can you add a signature?  Documents formats have to
> be
> designed with signatures in mind.  You can't tack a signature onto a
> document if the DTD doesn't allow it or the application doesn't expect
> it.
>
> <John>This is close to what we do in XFDL, but this requires the ability
> to
> say 'omit' some of the subelements of the given element.  Currently a
> manifest lists what we should 'keep'.   There is no way to say, "Sign
> everything in this element except for ...."</John>
>
> 3.  Add a resource to the manifest that refers to the statement "These
> resources were in this order".  Note that in the general case the
> resource
> does not have to be a part of the document containing the signature.
> This
> is almost the same as #1.  This approach could also be taken for
> asserting
> what is omitted from the document.
>
> <John>Another interesting solution.  Could you elaborate on how you see
> this
> doing omission?</John>
>
> 4.  Add a resource to the manifest that refers to the assertion "the
> resources in the signature were in the same order as in the manifest".
>
> <John>Yes, this is what I said above.</John>
>
> In addition, I believe that for some applications the assertion in #4
> could
> be an implicit assumption of the document format.
>
> <John>I think this would be pretty rare.</John>
>
> It is the application's responsibility to verify the resources in the
> manifest against the actual resources, so verifying the order against
> the
> order in the manifest may just
> be an additional part of that process for some applications.
>
> <John>
> Part of what I'm getting at is that, at the very least, that order of
> non-continuous portions of a resource needs to be dealt with at some
> level.
> The other part is that I really don't think we can pass off so much of
> the
> actual signature verification to 'the application.'  Pass the buck, and
> set
> up a "somebody else's problem" field around it.  No.  It should matter
> to us
> that we can create an XML signature that verifies as correct yet we can
> change the document in very meaningful and possibly harmful ways.
>
> By pushing this off to 'the application' we create this scenario where
> it is
> impossible to produce document processing software like workflow engines
> that use XML signatures unless those engines are aware of the
> pecularities
> of every XML document type created by every Tom, Dick and Harry.
> Further,
> that software would need to be upgraded every single time somebody puts
> out
> a new document type for their own data structure.
>
> My highest preference would be that the hash value itself capture as
> much
> information as possible.  What I really want is to create a message to
> be
> signed from the manifest.  Some things are external and some things are
> marked 'internal'.  Many 'internal' resource elements may point to
> portions
> of the same Web resource.  The portions of that web resource  should be
> obtained from the resource in the order they appear in the web resource
> regardless of the order of listing in the manifest.  The message
> constructed
> in this way is what should be signed.  Naturally, this is not counter to
> but
> rather a proper superset of what is currently proposed for
> canonicalizing
> the manifest in the Brown draft.
>
> </John>
>
>
> In the general case, one cannot assert an order for the resources in the
> manifest because they will quite likely be pointing at different
> documents.
>
> <John>
> I'm not concerned about what happens in different documents.  I didn't
> ever
> say that was a problem.  My problem is with the order of portions of the
> same document.  The order of listing in an XML document implicitly
> conveys
> meaning, as does element depth and attributes of all ancestors, and tag
> names of all ancestors.  We need to be capturing all of those pieces of
> information in the ancestor chain that convey meaning upon a given
> element.
> I just read the c14n spec, and it simply does not account for this.
> I posted a prior email discussing this in greater detail.
>
> http://lists.w3.org/Archives/Public/w3c-ietf-xmldsig/1999AprJun/0032.htm
> l
>
> John Boyer
> Software Development Manager
> UWI.Com -- The Internet Forms Company
>
> </John>
>
> -Mark Bartel
>
>

Received on Friday, 30 July 1999 12:02:05 UTC