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

> 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.

I wasn't saying that signatures would cause conflicts.  I was saying that
they needed to be included in the DTD (or other definition).

<John>
Why would dsig elements need to be included in the DTD for other document
types?  During the DTD validation for document type X with X.dtd, shouldn't
the validator ignore the elements that claim to be in the the dsig
namespace?  X.dtd should not need to be changed.
</John>

> Secondly, DTDs are not required.

I never said they were.  That's why I kept using expressions such as "DTD
(or other definition)".  There's always a document definition.  Perhaps it
is very loose, perhaps it specified in a format other than a DTD, perhaps it
is merely implied by the application.

<John>
True, but most if not all XML extension languages that have 'loose'
validation are also loose interpreters.  If there is an element which is not
understood, then it is ignored by the application but preserved in the
document since it is assumed to be an element specific to another
application that must process the document.
</John>

> 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.

Capturing this detail would be one of many reasons why people use definition
formats other than the XML DTD.

<John>
Certainly not in the cases of the two examples I gave.  I want someone to be
able to intersperse fields, labels, popups, etc. in any configuration they
desire, so it is impossible for me to say that a particular configuration of
fields, labels and popups is invalid by DTD validation.  All of them are
valid, but the signature needs to capture the specific order in which they
appear since the 'build order' can affect how the markup is interpreted.
</John>

> 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.

The problems with HTML forms are so great that the XHTML forms group has
decided to start from a clean sheet.  XHTML is very strongly emphasizing
separation of presentation and data, and the issue just doesn't arise.  XFA
forms similarly avoid the problem, with the form definition separate from
the form data, not interspersed.  Interspersing presentation/definition and
data is contrary to the basic philosophy of both the Web and XML.

<John>
1) I'm quite well aware of the XHTML forms subgroup since the guy in the
next cube from mine is in that subgroup.

2) What does separation of presentation and data have to do with this
conversation?  Perhaps you think separation of data and presentation is
something that cannot be done in XFDL?  You'd be wrong, of course, but that
kind of discussion really doesn't belong in this discussion group, so if
you'd like to talk about XFDL, you can email me personally.

3) As for HTML, have you ever seen the format of an HTML form submission?
If that isn't separating the data from its presentation, I'm afraid I don't
know what is.  In fact, the act of signing the data of an HTML form
submission is a great example of how badly wrong technology can go.  If you
just sign Field1=500&Field2=50000, you can't really assert that the person
who signed was agreeing to pay $50000 at $500 per month or $500 per year for
a $50000 life insurance policy, or $500 for 50000 pumpkin seeds.

4) You can separate what you think is the data from what you think is the
presentation all you like, but when you show them to a user, they are one
united thing.  My view is that once the user elects to sign, they are really
signing the one united thing because the data and presentation together
capture the essence of what the user actually believes he or she is signing.
They don't have much of a clue whether it is PDF, HTML, XFDL, or any other
existing software, so you have to capture within the signature enough
information to regenerate what they were looking at when they decide to sign
(where I use looking at as a metaphor for perceiving in some way, for those
who happen to be blind).  Hence, that which you believe is data and that
which you believe is presentation are all data input to the digital
signature, and the whole wonderful "web philosophy" thing goes right down
the toilet the first time some lawyer disputes a digital signature because
he can call the technology into question in the way I've described above.

</John>

> 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.

This makes me uneasy.  If you are looking at it from the user perspective,
they will never see the XML anyway.  They will see a form on the screen.  It
does not make a difference to them whether the signature had the xml tag on
it or not.  They probably won't know what XML is.  From a technical
perspective, you can no longer point at what was actually signed, since the
hashes were created over some virtual document.  Finally, this doesn't make
any sense at all when the links in the manifest point into different
documents.

<John>
Yes, they will never see the XML in the same way that they don't see
Microsoft Word's internal data structures or PDF's binary data structures,
or the decompression algorithms that must be run on PNG and JPEG images.
If you adopt this position, then what you're saying is that most reasons why
we'd want to sign XML are useless.  I don't agree with this position.  I
think that if the JPEG, PNG, PDF, XFDL, etc. accurately captures the essence
of what the user was looking at, then signing that is a viable alternative
to ruling that the only thing we can really sign are 24-bit bitmaps.

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

</John>

-Mark Bartel

Received on Thursday, 29 July 1999 14:26:08 UTC