RE: RE: Omitting Location and Transforms from SignedInfo

Hi Rich,

Cop-out is a good turn of phrase considering where you work!

Anyway, whether it is a cop-out really depends on whether you see Location
as a URL that has a specific meaning that allows core behavior to
dereference it without application-specific behavior, or whether you see
Location as a 'hint' to be resolved by an application-specific callback
function that utilizes local caches, alternate definitions of URLs (which
may be date specific resolutions involving database lookups), etc.

In the former case, it would be a cop-out, esp. given the availability of
the W3 libs.  However, if Location as 'hint' is the direction that the WG
wants to go in, which seems to be the case based on the poundings I've been
getting, then there is no logical difference between our positions, in which
case I would prefer that we move application specific behaviors to manifest
where all the other application-specific behavior is located.

Also, I should point out that you also need base 64 decoding to be outside
of SignedInfo.  Mark Bartel suggested making this another attribute, but it
doesn't work.  When your resource is inside the document, it is base64
encoded as a text node child of some element.  An IDREF gets you the
element, but you need to run a child::text() XPath on it before the base-64
decoder runs, so the base64 decode needs to be a transform, and there are a
lot of people, including me, who do not want to see all transforms omitted
from the SignedInfo.

I only want to see a very specific transform omitted (the one that says
base64 decode).  Which brings us back to transforming the SignedInfo. Since
most of the WG hates that idea (including you I think), your scenario
becomes doubly application-specific.

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
rhimes@nmcourt.fed.us
Sent: Monday, November 22, 1999 10:02 AM
To: jimsch@Exchange.Microsoft.com
Cc: w3c-ietf-xmldsig@w3.org
Subject: Re:RE: Omitting Location and Transforms from SignedInfo



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.

Thanks,
Rich

Received on Monday, 22 November 1999 14:32:20 UTC