Re: Another requirements question

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