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

Re:RE: Omitting Location and Transforms from SignedInfo

From: <rhimes@nmcourt.fed.us>
Date: Mon, 22 Nov 1999 11:02:09 -0700
Message-Id: <9911229432.AA943293754@nmcourt.fed.us>
To: <jimsch@Exchange.Microsoft.com>
Cc: <w3c-ietf-xmldsig@w3.org>

John Boyer wrote:
>It would be much cleaner to design a syntax that, by its design, does not
>have us chasing things down outside of the current document.

Just want to say for the record that I think it would be a mistake to restrict
object location to internal.  It probably makes sense for XFDL, but we shouldn't
make this restriction.  Suppose I have a data repository of countless huge
documents that are signed by their creators (as is the case in the courts and
other data repositories.)  Suppose further that many of those documents are not
in XML format (e.g. many are scanned, in PDF, etc.)  I want them signed in their
"native" format (along with SignedInfo stuff).  I would like to store the XML
reference documents (some might call them "headers" or "cover sheets") in a
document management system or object database without having to include the
target object BLOBS in the XML documents.  Note that I would have to
base64-encode many of the objects in order to make them internal, which should
be a different format than the format the object had when it was signed (IMO),
thus the transform would have to be "variable" (sometimes base64-encoded.) 
Again, I'd like base64 to be optional without breaking the signature.

Why not include the BLOBS in the XML document that signs them?  We have found
that including BLOBS in a database slows down access and increases scaling
problems.  People (applications) viewing information about a document may or may
not want to verify the signature.  Also, storing documents in their native
format (and pointing to them) has advantages.  You can read them directly with
their native reader application if necessary (e.g. Acrobat), and current
indexing packages work on native formats.

I also think it would be a mistake to push the problem off to a manifest and
turn it into an "application" problem.  C'mon, the problem can't be that
difficult.  Just allow locations outside SignedInfo.  Don't think that's very
pretty?  Just take a look at the hacks that result if we don't allow it.  I will
be using off-the-shelf software or APIs that implement core behavior.  What if I
want those external bits signed?  Core capability would be worthless, and I
think it is a cop-out.  That doesn't mean we should necessarily disallow
application-specific manifest as an option.

Received on Monday, 22 November 1999 13:02:59 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:32 UTC