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

This is partly a response to this email and partly a continuation of
response to the last.

Firstly, since digital signatures are in their own namespace, they shouldn't
conflict with the DTD for the rest of the document.  If the namespace spec
doesn't account for this, then namespaces themselves would seem to be of
very limited utility.

Secondly, DTDs are not required.

Thirdly, there are lots of languages (e.g. HTML, XFDL) that can have DTDs
while still not capturing the order at the level you're thinking of.  A form
(in either HTML or XFDL) can have any number of field elements interspersed
with elements with other tag names.  Something besides the tag name is used
to identify the element.

Fourthly, what I'm driving at is not just that we should have the option of
adding the signature element inside of the root element (so, for example,
XFDL form plus signature element is still XFDL form).  I'm driving at the
idea that it should be possible for the actual message for which an
encrypted hash is generated to be the same kind of XML document as the one
into which the signature is placed.

For example, when I create an XFDL signature, the message I sign starts with
the xml declaration followed by the start tag for XFDL.  If I take the
ACTUAL message that was hashed, I can feed that directly into the XFDL
viewer and LOOK AT what got signed.

I'm not saying everyone has to do it this way (e.g. how do you LOOK AT a
protocol message?).  I'm saying that this should be an option, whereas right
now we sign a manifest.  Why should this be an option.  Cleanliness.  The
closer we can get to telling users of this technology that the encrypted
hash is a direct hash of the XML that actually represents their document,
the easier it will be to get users to adopt the technology.

Richard Himes and others have already expressed the idea that signing PDF
should be done on the actual binary of the PDF rather than the base 64 or
even the XML encoded plain version of the PDF.  This is because more users
are scared away with each translation of the data that we do.  Signing a
manifest full of hashes is easily as much of a conceptual reach as base64
encoding a PDF document...

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


-----Original Message-----
From: w3c-ietf-xmldsig-request@w3.org
[mailto:w3c-ietf-xmldsig-request@w3.org]On Behalf Of Mark Bartel
Sent: Wednesday, July 28, 1999 12:10 PM
To: 'w3c-ietf-xmldsig@w3.org'
Subject: 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:47:42 UTC