note on requirements (was RE: verifying order of resources in a d ocument)

My suggestion #2 below brought to mind Dan's comments about the statement in
the requirements 

"An XML document of a certain type must still be recognizable as its
original type when signed." 

At first blush this seems to imply that one should be able to tack a
signature onto any old XML document.  But if the DTD (or other definition)
doesn't permit a signature to be added, then you can't add a signature to
the document and still have a valid document.  Of course, you can create a
separate document that signs the first, but that is not what I took this
statement to say.  Perhaps it should be clarified?  I believe this
requirement was trying to say something like "It should be possible to add a
XML-signature to the definition of any document type."  By definition I
don't necessarily mean DTD.  Basically the idea is that the signature should
be a reusable element or something to that effect?

-Mark Bartel


-----Original Message-----
From: Mark Bartel
To: 'w3c-ietf-xmldsig@w3.org'
Sent: 7/28/99 2:46 PM
Subject: verifying order of resources in a document

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.

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

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.

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.

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

In addition, I believe that for some applications the assertion in #4
could
be an implicit assumption of the document format.  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.

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.

-Mark Bartel

Received on Wednesday, 28 July 1999 15:10:27 UTC