Peb Op, etc. Re: Fw: XML versus ASN.1/DER blob

I'm fine with the "inner signature" being a binary blob.  I certainly think
Pen Op and the like should be accomodated.  But that is not at all the same
as saying that what is called the Manifest in Richard Brown's proposal, a
structured element which can include arbitrary XML/RDF attributes, etc., in
it should be encoded with ASN.1/DER.

I think PenOp is about as strong as copy protection is/was but those who
want to use it shouldn't be stopped.

Donald

Donald E. Eastlake, 3rd
17 Skyline Drive, Hawthorne, NY 10532 USA
dee3@us.ibm.com   tel: 1-914-784-7913, fax: 1-914-784-3833

home: 65 Shindegan Hill Road, RR#1, Carmel, NY 10512 USA
dee3@torque.pothole.com   tel: 1-914-276-2668



"John Boyer" <jboyer@uwi.com> on 04/20/99 05:33:31 PM

To:   "Bede McCall" <bede@mitre.org>
cc:   "Dsig group" <w3c-xml-sig-ws@w3.org> (bcc: Donald
      Eastlake/Hawthorne/IBM)
Subject:  Re: Fw: XML versus ASN.1/DER blob





Hi Bede,

Actually, you start out incorrect, but then begin deriving some of the very
ideas behind handwritten signature technologies.  First off, by handwritten
signature technology, I am not referring to a simple signature bitmap
(although one can be included for display purposes).

PenOp is an example of a technology that binds the handwritten signature to
the document.  Further, they would argue that they do a better job of
binding the document to the signer than cryptography does.  I'm not sure I
agree that they do a better job than cryptography in any area of signature
technology, but I'm not prepared to argue that the technology is useless,
in
part because several deployments of XFDL use PenOp signatures.

They bind the document to the signature as follows:

1) 90 or so measures of a person's handwriting style are recorded into a
"biometric token".
2) a secure hash of the document is computed (sha-1 or md5)
3) 1 and 2 are concatenated and the result is encrypted

Now, as I just said in a very pleasant phone conversation with Don
Eastlake,
I'm quite sure that the use of encryption is simply to obfuscate matters
and
does not represent a cryptographic strength security solution.  Though a
tractable problem, it is still quite difficult and expensive to reverse
engineer this technology.  Therefore, it makes sense for many types of
deployments where one expects high volume, relatively low value
transactions
where the organization wants to avoid the cost and difficulty of setting up
a PKI for walk-in business.  It is probably not "reasonable doubt" to
assert
that the organization broke the signature technology since, based on the
value of the transaction, it is probably too costly to do that or it is
less
expensive to forge the person's signature (the "old fashioned" way).

So you see, the opaqueness of the blob (offered by the encryption) is how
these handwritten signature technologies can claim to bind the signature
(biometric data) to the document (secure hash).  Hence, if we only support
signing technologies that allow a human readable format, then we are, by
definition, excluding handwritten signature technologies.

Maybe this is what the group wants to do, but I think it is at least
important that we know we're making this choice rather than having it sail
by unnoticed.  In UWI's case, I'm pretty sure our executive will not want
to
throw out a good revenue stream because of the standard, so XFDL will most
likely to continue to support this form of 'signed' XML.  It will just be
unfortunate that the signed XML standard cannot accommodate all kinds of
signed XML.

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company
jboyer@uwi.com

>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 Wednesday, 21 April 1999 21:37:29 UTC