Re: Fw: XML versus ASN.1/DER blob

>>The pen people's biometric tokens are encrypted blobs containing biometric
>>measures of the act of signing as well as a sha-1 or md5 hash of the
>>document being signed.  The biometrics identify the signer, the act of
>>signing implies authorization (same as paper), the hash authenticates the
>>document content, and the encryption binds the two together.  The pen
people
>>claim that this signing technology offers an electronic solution that is
at
>>least as secure or substantially more secure than the paper signatures
that
>>we currently accept.
>
>There seems to be general agreement that whatever we develop should be able
>to accomodate multiple signature technologies.  There also seems to be
>agreement that it is not the work of this group to judge the strength or
>merit of any particular technology.

Your comment about judge the merit of certain signing technologies is
particularly important in the case of pen-based signatures.

As for whether there is agreement that we should develop support for
multiple signature technologies, I'm not so sure this is the case.  As I
showed in the most recent email, if you parameterize the signature
technology in markup, then you are deciding to limit support for signature
technologies to only those technologies that can be envisioned now.  If we
want to support new security ideas in the future, we have to change our
spec, our DTD's, and our software.

Furthermore, by parameterizing the signatures in markup, you also have to
say what the tags mean, which means you can't create an implementation that
is demonstrably compliant with the spec unless you also include the
cryptographic layer.  Did it really encrypt the hash with RSA?

>
>But it does seem necessary to understand the requirements posed by known
>signature technologies on the specifications we develop.  Therefore, I
>would assume we need to understand how signing using biometrics relates to
>the process we are more familiar with: that of encrypting the hash of a
>signature block using the private key of a public keypair.
>

The relationship is that both have this form
    SignatureBlob = Sign(M, ...);
    Verified = Verify(M, SignatureBlob, ...);

In the case of the RSA, Sign is implemented as Encode(Encrypt(hash(M, ...),
PrivateKey)) and verify is implemented, at least in part, as a test of
whether hash(M, ...) is equal to Encrypt(Decode(SignatureBlob), PublicKey).

We should recognize any technology that conforms to Sign() and Verify(), not
just the certain ones such as the ones in the current spec.

>Maybe I'm a bit dense, but I can't figure out the explanation provided
>above.  What "encryption" binds the identifying information unique to the
>signer and the description of what is being signed?  Could you take us
>through that operation in more detail?
>

The encryption offered by the pen-based people is not, in my opinion,
cryptographically secure.  The encryption means that it is impossible to
break the signatures without reverse engineering their products.  This is a
difficult but certainly tractable problem.

The point is that it is being used as an example.  You can argue about the
merits of this particular example all you like, but that would be missing
the point.  The point is that we cannot predict what technologies will come
in the future.  So we either write a spec that has to change every time
something new comes out that doesn't have the same parameterization we
originally envisioned, or we write something generic enough to facilitate
incorporation of new signature technologies without having to change the
core spec, DTD, software, etc.

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

>Thanks.
>
>Alan
>___________________________________________________________________________
>Alan Kotok, Associate Chairman                          mailto:kotok@w3.org
>World Wide Web Consortium                                 http://www.w3.org
>MIT Laboratory for Computer Science,  545 Technology Square,  Room NE43-409
>Cambridge, MA 02139, USA     Voice: +1-617-258-5728    Fax: +1-617-258-5999
>

Received on Wednesday, 21 April 1999 15:30:58 UTC