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 Thursday, 29 July 1999 12:39:07 UTC