- From: John Boyer <jboyer@uwi.com>
- Date: Wed, 16 Jun 1999 14:16:24 -0700
- To: "Bugbee, Larry" <Larry.Bugbee@PSS.Boeing.com>
- Cc: "Dsig group" <w3c-ietf-xmldsig@w3.org>
Hi Larry, This particular topic was the source of a fair bit of debate by the group back in April. To understand what follows, you may want to get a copy of the current Brown IETF draft for XML digital signatures. The issue was that although we want to express signatures entirely in XML, seemingly except for the 20 byte encrypted hash to be placed in the <Value> tag of the <Signature> element. Expressing signature entirely in XML moves everyone closer to the ideal of "globally secure resources". However, since most of today's crypto technologies don't spew out XML, it leaves the application developer in the nasty position of having to wade through the binary signature blobs to translate them into XML. This is nasty, but not the end of the world. What is the a problem is trying to parse through a binary blob if it happens to come from an 'electronic signature' engine as opposed to a 'digital signature' engine. The reason is that, although not cryptographically strong, the good electronic signature packages have the tendency of pairing a biometric reading (handwriting, fingerprint, etc.) with a hash of the document and encrypting both, usually with a proprietary encryption scheme. These systems 'obfuscate' the binary blob, and this obfuscation represents the only real security offered by the system. Hence, breaking the encryption (which is feasible but difficult) in order to express everything in XML would break any hope of security in these systems. To make a long story short, members of the group have, with varying degrees of patience, acknowledged that this issue could be addressed by an 'abuse of notation' as one member put it. In other words, stick the whole electronic signature blob in the <Value>, and use whatever parameterizations are necessary in the <Manifest> to indicate to the verifier that the algorithm is not RSA or what have you, but rather a particular 'electronic signature' package. It seems to be the hope that the optics around 'abuse of notation' would ultimately encourage an 'electronic signature' standard to emerge such that we can get back on track with the ideal of globally secure resources. However, this is unlikely since a major component contributing to the obfuscation of the 'electronic signature' is the fact that the encryption used is proprietary. If we knew, for example, that a publicly known algorithm were being used, we could simply search the code modules of the 'electronic signature' package for the key (or perform a similar, relatively easy process). Still, with the abuse of notation idea in hand, it should be enough to create applications. The part that stings is that it would require one to have vendor-specific software to verify the signatures. Perhaps 'electronic signature' companies could be coerced into giving away free verification-only software... John Boyer Software Development Manager UWI.Com -- The Internet Forms Company jboyer@uwi.com -----Original Message----- From: Bugbee, Larry <Larry.Bugbee@PSS.Boeing.com> To: 'reagle@w3.org' <reagle@w3.org> Cc: 'w3c-ietf-xmldsig@w3.org' <w3c-ietf-xmldsig@w3.org> Date: Wednesday, June 16, 1999 1:40 PM Subject: Another requirements question >Joseph et al, > >Continuing my earlier post... > > 4. Are there plans to support signatures lesser than "digital"? > > Some jurisdictions give legal standing to, and differentiate > between, digital signatures and electronic signatures. A > digital signature is typically cryptographically strong while > an electronic signature may be nothing more than a digitized > graphic of a handwritten signature. No interesting > cryptography may be involved and the burden of proof may be > on the relying party, but electronic signatures have legal > standing. Will there be a way to programmatically recognize > electronic signatures? > >Larry >
Received on Wednesday, 16 June 1999 17:14:26 UTC