Fw: XML versus ASN.1/DER blob

Hi Donald,

>>(3) XML Signature Syntax.  There appears to be controversy here.  Some
want
>>to start with CMS/PKCS#7 but map it into XML syntax and extend it to meet
>>the requirements, presumably resulting in something like the Richard Brown
>>proposal.  Others want to just use a PKCS#7 binary blob.
>>     The blob approach loses all of the transparency and extensibility of
>>XML.  It is not clear that it can meet the requirements for support of
>>keyed hashes.  You are locked into having two mutually alien sets of
>>encoding/decodig logic: XML and ASN.1/DER.
>>     On the other hand, wtih XML syntax as show in the Richard Brown
>>proposal, you do have the readability and extensibility that are goals of
>>XML.
>>     Quite frankly, if you go with the blob, I don't see any justification
>>for calling the result an XML digital signature.
>>

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".

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.

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.

More generally, the approach we use in XFDL is one which says that the
signing engine produces a 'black box', which we base-64 encode and put into
character content.  A verification uses the verify engine on the base-64
decoded 'black box'.  This approach simplifies integration of new
cryptographic technologies, frees them from the requirement of XML awareness
(XML isn't the only format in the world, after all), and allows support for
non-cryptographic signature technologies.  Most importantly, it reduces the
burden on the W3C/IETF reference code implementers.  If we adopt a spec that
is heavily cryptographic, it may require the reference implementations to
contain enough of a cryptographic interface that they cannot be freely
distributed due to export restrictions.

By comparison XFDL, defines a signature technology interface of only a dozen
functions, and a new signature technology can be incorporated in two to four
person weeks.  We've done this for CryptoAPI, Netscape, Entrust, and PenOp
so far, so this is a pretty safe estimate.  Because the integration is at
such a high level, there is no export trouble on our signature engine.  The
only restrictions are on the cryptographic modules themselves, which are
external to our core product.

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

Received on Tuesday, 20 April 1999 13:18:36 UTC