W3C home > Mailing lists > Public > w3c-xml-sig-ws@w3.org > April 1999

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

From: Bede McCall <bede@mitre.org>
Date: Wed, 21 Apr 1999 15:23:22 -0400 (EDT)
Message-Id: <199904211923.PAA14616@idiot-savant.mitre.org>
To: w3c-xml-sig-ws@w3.org
Maybe I'm confused, but as far as I can make out, PenOP's collection
of "90 handwriting metrics" is being used as a poor man's version of a
"certificate" or (more accurately?) as a "salt" value, and one which
some claim is not well chosen.

In any event, the actual signing is still done using hashing and
encrypting:  without the crypto in step 3, the PenOP scheme couldn't
produce a useful signature -- even for the stated target market of
low-value, high-volume transactions.  The key for doing step 3 still
has to come from someplace, though, and the crypto algorithm is itself

Framed this way, I don't understand how PenOP's scheme doesn't fit, so
I don't understand what the issue is.  As Phill points out, we will
want to permit arbitrary signing schemes and PenOP's scheme is
basically just one more member of the herd at this level.

For the sake of ensuring interoperability, we need to specify a (set
of) "MUST" algorithms for signing, none of which should be proprietary.
Hence, while we may try to allow something like PenOP's proprietary
"signing" operation, we obviously can't make it an explicit part of a
Signed XML spec.  As Phill also points out, though, there are other
proprietary biometric "signing" schemes lurking out there, so PenOP's
is undoubtedly only the first one we've seen.  So, I think we will
have to somehow accommodate these and other schemes.

I think this means we'd need to have a pointer in the signature block
to what one needs (when it's something other than the default) in
order to validate the signature.  This pointer could be a URI, an
OID or ...  Other than saying that the pointer refers to some external
resource and that it should be unique, I don't think we'd need to
define any of the semantics involved because these will invariably be

On the other hand, it might be useful to include a syntax (preferably
by reference) for one or two common reference types, plus a "quoted
blob" to allow for new or proprietary references.  One obvious problem
I see with a "quoted blob" is that some application developers would
undoubtedly yield to the temptation to use this to embed executable
content in signature blocks.

Received on Wednesday, 21 April 1999 15:23:28 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:44:59 UTC