RE: Fw: XML versus ASN.1/DER blob

>   From: "John Boyer" <jboyer@uwi.com>
>   Date: Tue, 20 Apr 1999 10:22:42 -0700
>
>   [ . . . ]
>
>   The declared result we are trying to achieve is "Signed XML" which
>   is not necessarily the same thing as an XML digital signature.
>   Also, the declared result is "Signed XML" and has not been
>   officially called "Cryptographically Signed XML".
>

But the only tool we have for signing electronic documents, whether
they use XML or not, is cryptography.

>
>   Does the signature itself have to be human readable, or does an
>   application put functions in place to query the signature blob to
>   obtain the information it needs.  We will be able to achieve the
>   same end results whichever format we choose.
>

OK, in some applications, it would be extremely useful or required
that some artifact of signing we will call a "sign" could later be
displayed in "human readable" form (e.g., as a digitized image) along
with the document.  The only really important feature of this artifact
is that it can be made visible.  Ignoring semantics and meaning for
the moment, the binding between a sign and an underlying document
is *not* human readable.  This binding is the result of what we're
calling a "signature" or "act of signing" which is necessarily done
cryptographically.

Note that a human-readable digitized sign can be signed to prevent
tampering, perhaps using steganography.

>
>   In my opinion, handwritten signatures are not as safe from
>   tampering as true cryptographic signatures, but they do achieve a
>   fairly high level of security from encrypting the biometric token.
>   Further, this is the only security method I've seen them use, so if
>   we do want blob transparency or even translucency, then we are
>   deciding to eliminate handwritten signatures. 
>
>   [ . . . ]
>

The basic problem with handwritten signatures is that they can't be
bound to a particular document without an extra step.  Specifically,
you can't simply store a signature bitmap with a digital document and
later claim that the mere fact of "close proximity" (largely a fiction
when you get down to the device level) between these objects in your
logical file system implies that the two things necessarily belong
together.  The situation is almost exactly the same as the one you
have with a photocopy of a "signed" document:  it's easy to "edit"
photocopies, so a photocopy of a signature is essentially worthless.
A collection of "handwritten signature bits" is equally worthless for
the same reason.

When you sign a paper document, what binds your signature to the
document happens at the mechanical/chemical level.  Using existing
technology, the only way to bind signatures to digital documents is
through cryptographic means.  I'm not a cryptographer, but maybe a
digitized handwritten signature might be used as a source of keying
material.  In the end, though, you still need a way to bind the
handwritten signature bits (or any biometric "signature", like a
retina scan or a thumbprint) to the document bits.

By itself, a digitized handwritten signature is basically a display
element or attribute you might want to cryptographically bind to a
document.  This doesn't mean that handwritten signatures aren't
important -- particularly for legal documents -- mainly because
humans couldn't possibly recognize or describe their own "digital
signatures".

I think part of the problem here comes from the fact that we overload
the terms "signature" and "signing".  For example, cryptographically
"signing" something has side effects that make the act of signing
traceable to something only the signer possesses (specifically, a
key).  A "digital signature" only exists as some side effects of
signing.  These side effects are different each time you sign
something different, so you can't be expected to recognize or describe
your "digital signature" any more than you can be expected to
recognize or describe the unique mechanical/chemical binding that
exists between your handritten signature and a particular sheet of
paper.


--Bede

Received on Tuesday, 20 April 1999 16:36:01 UTC