- From: Richard D. Brown <rdbrown@GlobeSet.com>
- Date: Tue, 20 Apr 1999 18:46:39 -0500
- To: "'John Boyer'" <jboyer@uwi.com>, "'Bede McCall'" <bede@mitre.org>
- Cc: "'Dsig group'" <w3c-xml-sig-ws@w3.org>
John, Though it is probably not the subject of this mailing to discuss about the strength of a particular signature technology, I cannot resist asking what makes the PenOP scheme secure. Unless, the encryption that you refer to in step 3 makes use of a strong public-key algorithm, I do not get it. Attaching a biometric token to a message is no more secure than attaching a digital certificate to the message - in fact this does not prove anything... Richard D. Brown > -----Original Message----- > From: w3c-xml-sig-ws-request@w3.org > [mailto:w3c-xml-sig-ws-request@w3.org]On Behalf Of John Boyer > Sent: Tuesday, April 20, 1999 4:34 PM > To: Bede McCall > Cc: Dsig group > 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 Tuesday, 20 April 1999 19:46:18 UTC