W3C home > Mailing lists > Public > w3c-xml-sig-ws@w3.org > April 1999

Re: unparsed entities

From: John Boyer <jboyer@uwi.com>
Date: Wed, 7 Apr 1999 14:02:47 -0700
Message-ID: <006b01be813a$00223280$9ccbf4cc@kuratowski.uwi.bc.ca>
To: <rdbrown@GlobeSet.com>
Cc: "Dsig group" <w3c-xml-sig-ws@w3.org>
Hi Richard,

>I am certainly pushing a bit too far but, considering the lack of
>in the rendering of document by commercial browsers, I feel that you'd
>better save a copy of the user-agent along with the transaction. The point
>is that in most circumstances, signing at the presentation layer does not
>make a lot of sense or, at least, does not increase the overall security of
>the system. For form signing by human being, I would rather propose
>signature of the message semantics and ensure the reliability and
>of the user-agent (i.e. plug-ins or style sheet). As we already do with
>smart card readers, it shall be possible to require authentication of the
>user-agent in the signature process.

Actually, you are not pushing too far here at all.  This is a real and
sticky issue-- a Pandora's Box, if you will.  Fortunately, it takes us out
of the realm of what signed XML could possibly do.  It is a problem that
pervades all digital signature software, whether you are trying to sign XML,
XFDL, PDF, a word processing document or even ASCII text.

In legal circles, it is of value to demonstrate 'best effort' in proving the
authenticity and authorization of a transaction.  Signed XML can guarantee
these things in any context short of assuming that the software used by the
signer was 'unauthorized' by the manufacturer but was instead modified
specifically to trick the signer.

We often argue that XFDL represents a better effort than, say, signing user
data plus the set of Java classes used to render that data.  The reason is
that XFDL relies on XML's human readability whereas people can't read Java
byte codes.  XFDL can be read and compared to the specification in terms of
behavior.  Ultimately, though, XFDL, PDF, Java byte codes, XSL stylesheets,
and even simple ASCII text are all document formats that require an
interpreter, virtual machine, editor, wordprocessor, etc. to render them.
How can we guarantee that the rendering engine which presents the document
to a user and affixes the user's signature is, in fact, an authorized piece
of software?

The answer does not lie in signed XML because the XML document is
subordinate to the software.  In particular, once the unauthorized software
is running on the client box, it has access to the user's private key
material and hence can do a great deal of damage.  Such software actions
must be considered in the same light as the actions of a software virus.

This, of course, is where signed XML stops and signed code starts.  Is the
operating system itself secure?  Does the operating system provide support
for signature verification before running a piece of code?  Storing a copy
of the rendering engine in the document will not lead to a more secure
system since unauthorized software can store whatever it likes in a document
(the document is subordinate).

Microsoft, for example, provides mechanisms for validating signed code, and
it also verifies the signature on any cryptographic service provider before
running it.  So there is some awakening to these ideas/needs within the
computing industry, but the efforts are still in a primitive state despite
the increasing number of politicians we see performing digital signatures
for photo opportunities.

To conclude this comment block, creating signed XML will still represent a
best effort without storing a copy of the rendering engine in the document.
But, yes, until these ideas find support in our OS's, I would have to say
that it is a good idea for users to manually validate the software and even
store a copy of the rendering engine in whatever data warehouse is used to
store the copies of the transactions themselves.

Manual validation does not need to be difficult.  It should be the case that
the rendering engine manufacturer should be unrelated to the parties with
whom you plan to transact your business.  Take, for example, an insurance
company.  If you want to buy a policy online, then don't download the
browser, XFDL plugin, Java VM, etc. from the insurance company.  Or if you
do, the code should be digitally signed by the original manufacturer.

>> Need for packaging relevant external entities

>This is certainly a requirement, which is actually considered by the
>Signature for XML Proposal. However, the ability to package
>external/unparsed entities does not imply that the Signature Standard shall
>require compliant implementations to "chase" such external entities. This
>only implies that the Signature Standard should allow authentication of
>packaged entities. Chasing and embedding such external entities in the
>signed document shall fall under the responsibility of the application
>framework that defines such a requirement in the first place.

First of all, this is really only a problem in protocols that permit the
separation of data and presentation layers.  Such a separation can be useful
for creating multiple views of a document, but computations can do the same
thing.  This, of course, is why XFDL doesn't permit the separation and
consequently why XFDL doesn't have this problem.

I do, however, see it as a problem for signed XML.  I agree that once
external entities have been packaged into the document, simply generating
the XML text as the message to be hashed is all that remains to creating a
signature.  As such, it is possible to conceive of a signature standard that
places the onus of packaging external entities onto applications.  So,
having the need to sign external entities does not in itself imply that the
standard should make statements about whether or how external entities
should be incorporated.  The implication comes from the need for limpidity
and interoperability.

In XFDL there are two elements that represent a signature.  The first, a
button, expresses the signature parameters, including a signature filter
that defines what portions of the document must be signed (this is where I
see the addition of material that expresses what external entities must be
dragged in).  The second object, a so-called signature element, represents t
he signature once it is created.  It takes a copy of all of the signature
parameters.  Therefore, the signature element clearly expresses what is

Due to XML design goals 1, 2 and 4, interoperability is even more important.
The signature standard should state how the markup will express the need for
inclusion of external unparsed entities, and it should state how those
external entities should be encoded.  If we do not state these things in the
spec, then everyone will create their own ways of expressing these things,
and software vendors like UWI.Com will not be able to produce generic
server-side document processing software that validates arbitrary XML

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company
Received on Wednesday, 7 April 1999 16:58:18 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:44:59 UTC