Re: Signed-XML and White Space?

Hi all,
----- Original Message -----
From: Bugbee, Larry <Larry.Bugbee@PSS.Boeing.com>
To: <'reagle@w3.org'>
Cc: <w3c-ietf-xmldsig@w3.org>
Sent: Wednesday, June 23, 1999 5:20 PM
Subject: Signed-XML and White Space?


> Hi Joseph,
>
> When you sign something you may or may not care about white space (extra
spaces, CR/LF, etc.).  For example, you might not care about white space if
it is a paragraphs of simple text and your assertion is that those words are
yours.  Line breaks are unimportant giving the renderer choices.  So,
signing words and their breaks is all that is necessary.

When you sign something you care very much about the whitespace. What you
are singing may in these cases be displayed as an "empty character"
represented in UTF-8 or ASCII, but it is in fact part of a binary stream of
data.

The hashing that produces the event representitive image processes the white
space as though it was what it is - an ASCII space or null character - so
just because it displays through the presentation engine as a "space" it
isn't an instance of "no data".

>
> If, however, the content were a purchase order, spacing is extremely
important lest the right numbers appear in the wrong columns.  Here we
should sign all the white space and have it preserved upon rendering.
>
> How should we go about this?  Do we care?

We care very much about this, but it is a key issue of what and how we treat
the objects we are trying to prove identity for, which brings us back to my
favorite subject of late, persistent objects... and how we manage signatures
and the like for digital instrument processing.

>
> Food for thought...

Yes lets think about this!!!

>
> Larry

As I have said to a number of people privately, the answer may be simply to
use a preprocessor pass on the XML source stream to enforece the construct
of the persistant objects.

>
>

Larry, since you opened this can of worms anyway, I ask the question "What
in the general XML use model provides a guarenteed forms traversa and
supports the consistancy of the objects represented in the XML data
stream?". The answer is that the browser that displays the file does this
since it processes the file in a top down manner, i.e. as a sequential
serial stream. This is an important concept since it addresses the First
Person use of a document.

No broswer - No document context
-------------------------------------
The problem is that as soon as we lose the browser, there is nothing in the
language itself to enforce forms traversal or any other type of flow control
with regard to the processing of the documents. Nor will there ever likely
be. XML as a derivitive of SGML suffers a number of the issues with top-down
presentation engines that rely on the data stream as part of their control
paradigm. This is an impirtant issue to contend with since the traversal on
a text document can be proven easily, but is linked to a facility to the
presentation engine, per say.

Why?
------
Now the reason this happened is IMHO simply the way we read, it is a 'paper
based' thing, but the reality is that if we don't use a presentation engine
to 'display' the document, but rather use it in the sense of an enabling
chit, then there is some pretty serious 'grey area' here as to the provable
content and intent behind the flow of the document itself. So then
persistence in objects and the abilty to under a demonsterable policy
framework, install this sense of what comes first, etc etc.

Paper != Digital
----------------
By comparison, these are use model issues that have not plagued paper based
processes becuase the paper document install their own flow. It's something
as a culture we agreed upon some time ago and this has just not happened for
the digital arena yet.

The Fix?
---------
As to the fix itself, my feeling is that the issue of the persistance of
objects is not something that can easily be addressed in a "Passive" display
engine without some active content management. To this end it seems like XML
should have a way of being both preprocessed and compiled and that there
*must* be a way of piping the output of the preprocessor into the display
framework or event processing framework, securely. (Note the use of the term
'must' here!). Right now all we do is interpret it.

    In the preprocessing instance #1 we should maybe try the "persistant
object" proposal I have sent to many of you (Anyone else who wants a copy
send me email to todd.glassey@meridianus.com, or if there is enough
interest, I will put it on the BERT standards page which our GMTsw arm
operates  - http://www.gmtsw.com/ietf/bert  )

    or in instance #2, there is another proposal that also dovetails into
the process. For the sense of legal documents, there may be a need in the #2
instance of stand-alone document to specify a framework for their
interpretation, and this should also allow for their "compiling" that is
being combined with the presentation engine primatives so that the module
can become an EXE and stand on its own two feet (without an external display
engine...)

Our  Resolve
--------------
Pending approval from the group, our folks could hopefully have the
pre-processor models ready for a topical persentation for the Oslo meeting
so they could at least be discussed, and while I won't be there personally,
Michael McNeil will be - so we should be able to hold a reasonable
discussion.

As to the Binary Document Harness that supports an XML carrier, I have
adraft that should fly on it in the next 3 weeks. Anyone interested in
working with us on this should contact me immediately.

Todd Glassey

Received on Thursday, 24 June 1999 10:55:26 UTC