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

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

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company

</John>

-Mark Bartel

Received on Wednesday, 28 July 1999 15:29:13 UTC