W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 1999

RE: verifying order of resources in a document

From: John Boyer <jboyer@uwi.com>
Date: Thu, 29 Jul 1999 12:29:54 -0700
To: "Mark Bartel" <mbartel@thistle.ca>, <w3c-ietf-xmldsig@w3.org>

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.

It seems preposterous to say that most applications will not care about the
order of the elements in a conversation about digital signatures.
For starters, it is wrong on a theoretical level.  Like it or not, the XML
1.0 spec does not forbid extensions languages from deriving meaning based on
the order in which the elements appear.  If you want that, use RDF.
Second, it is wrong on a technical level.  Even if you deal solely with
Third, it's wrong on a practical level, namely that you have not

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

You mention experience with forms, but what we're talking about is signing
forms.  Do you have experience with that?

Firstly, the ability to omit subelements is essential to such simple tasks
as supporting multiple signatures.

Secondly, we already support omission indirectly by allowing the manifest to
use # fragment identifiers (whether or not particular persons see a need for

What I'm suggesting is to modify the syntax to allow the direct expression
of omission so that we can accomplish 'document closure'.  We need to say
things like "This signature signs the whole document except for the second
signature".  In this way, a second signer can add a signature without
breaking the first, but both signers can be assured that the only thing that
can be added is the signature of the second signer.


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.

Who is 'we'?  Is yours the only workflow product in the world?  Does it
digitally sign documents?  Has it been doing so since version 1.0?  When did
version 1.0 come out?  Shouldn't it be possible to validate a digital
signature without needing custom code (read "a new hack") for each new
document type that comes out?
Let me rephrase that.  It is possible to create a signature syntax that
allows the validation of XML digital signatures without needing custom code
for each document type.  The question is whether we will create such a

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

Firstly, there are people both on the "document" side and the "protocol
message" side of signing XML that don't agree with the extra level of
indirection given by this manifest idea.  Don has some good points about
protocol messages, but others state that the extra level of indirection
makes things too slow.  There has also been no refutation of my basic point
that if the message I sign 'is' the same document type, then I can take the
signed message itself and send it to be rendered.  What you see (sense) is
what you sign.

Secondly, the email you cited discusses the importance of dealing with the
fact that URL content is not so stable as many would have us believe.  Heck,
even the URL to the XML spec stopped working! Fortunately, the Brown draft
permits packaging.  However, if you think about the classes of people who
have to deal with a document, you discover that there are users, there are
programs, and there are those who write the template documents to be used by
the former two.  It would be helpful, even if it is not part of the core
*behavior*, to at least allow a standard syntactic notation that tells
applications that they need to go get the resource and package it up.  We
could just leave such notation up to everyone's imagination (it's not a big
point, after all), but I still don't agree with Don's reasoning to the
contrary.  If the template document author indicates that something must be
obtained for packaging prior to signing, and the URI says something zany
like <greendreamssleepfuriously:foobar#987654321>, then why is it so darned
hard for people to envision the possibility that the user might be presented
with a dratted error message???

Thirdly, how did this follow from our discussion?

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


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

For starters, please see

Replies within...

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
proposing is not large, but the problem is insofar as any security hole
is a

1.  Have a DTD (of some sort) that orders the elements, and include it
the manifest.

<John>If you are requiring that the DTD be applied to validate the
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
in the manifest is the same order that the elements appear in the

2.  Arrange the document so that one is signing an ancestor of the
for which the order matters.  Obviously you can't do this if you don't
control of the document format.  However, if you don't have control of
document format, how can you add a signature?  Documents formats have to
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

<John>This is close to what we do in XFDL, but this requires the ability
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
does not have to be a part of the document containing the signature.
is almost the same as #1.  This approach could also be taken for
what is omitted from the document.

<John>Another interesting solution.  Could you elaborate on how you see
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
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
order in the manifest may just
be an additional part of that process for some applications.

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
The other part is that I really don't think we can pass off so much of
actual signature verification to 'the application.'  Pass the buck, and
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
of every XML document type created by every Tom, Dick and Harry.
that software would need to be upgraded every single time somebody puts
a new document type for their own data structure.

My highest preference would be that the hash value itself capture as
information as possible.  What I really want is to create a message to
signed from the manifest.  Some things are external and some things are
marked 'internal'.  Many 'internal' resource elements may point to
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
in this way is what should be signed.  Naturally, this is not counter to
rather a proper superset of what is currently proposed for
the manifest in the Brown draft.


In the general case, one cannot assert an order for the resources in the
manifest because they will quite likely be pointing at different

I'm not concerned about what happens in different documents.  I didn't
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
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
I just read the c14n spec, and it simply does not account for this.
I posted a prior email discussing this in greater detail.


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


-Mark Bartel
Received on Thursday, 29 July 1999 15:29:53 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 20:09:55 UTC