Re: Introductory article about XML Signatures and Best Practices

> Personally, I've given up worrying about impossibilities like digital
> non-repudiation.  Since a scrawl on a faxed letterhead can be a binding
> contract, in case of dispute it can always come down to human intent.

I agree and anybody who relies on a signature to mean all's okay without
having sufficient business processes to back it up will be defrauded.  You
more for wet signatures and electronic ones.  Ask any bank how many bad
checks are written with obviously bogus signatures?  Ask them how many
checks or credit card slip signatures are ever validated.  What wet
signature bureau do you go to in order to validate a signed piece of paper?
The answer of "zero" will likely shock some people, and when fraud is
detected, it's rarely prosecuted because the "business costs" are too high
to weed out identity fraud in the paper world.

I was mostly interested in hearing what people thought of this automated
digital signature validation system of XML Signature, yet understanding what
has been signed seems to still rely on human understanding and won't be
easily automated.

My gut tells me that XML Signature is really best suited for those automated
transactions in which there is a well defined "contract" defined by the XML
(via XML Schema, no doubt) with well known parties sending the transactions.
For example, an order entry system that generates fixed transations within a
group of customers/suppliers/manufacturers.

This became obvious to me because my company already offers an electronic
signature product based on digital signatures, and we store our data in an
open XML format when the signed data is exported from our system (otherwise
it's stored encrypted in a database).  When looking into converting to XML
Signature, we had to completely revise our signature scheme since XML
Signature is quite different from what we do (for example, we digitially
sign the actual data, rather than digitally sign a hash of the actual data).
But when we analyzed the "code benefit" of XML Signature, we couldn't find
any.  Using the Java JCE for encryption, our code that calculates a digital
signature over the data and metadata being signed was basically 16 lines of
code, most trivial calls like "sig.update(dataElement);" -- hashing in the
data.  The coding savings of using XML Sigature to calculate/verify the
signature was minor, yet the cost overhead of transforming the data into XML
and the having it go through the parser is substantially greater.  Our
throughput has gone way down, and yet there is ZERO perceivable benefit for
our customers since they still rely on our application to present the
contracts, apply the signatures, revalidate signatures (automatically each
time they are presented with the contract), and look at the detailed
information held about the signature and the signer.

Anyway, I guess my question was a bit off base in that I was asking if it
made sense as an electronic signature standard when I really was trying to
see if people thought XML Signature was best used for all electronic
signature applications or just those that can be fully automated.  In our
world, a contract is generally in a Word/PDF document, so having an
automated digitial signature verification scheme seems to offer very little
as a human must analyze the contract, and our application already did the
digitial signature processing for them.  Presumably, the benefit is such
signed data should be verifiable using other people's tools easily, but
again, doing the digital signature verification is only a small step in
validating a signed contract is appropriate and legally sound (for example,
if the data is a "last will & testament," then it's not legal in the U.S.
because the E-Sign Act does not allow such things to be e-signed).

David Wall

Received on Saturday, 14 December 2002 16:51:55 UTC