- From: Bede McCall <bede@mitre.org>
- Date: Wed, 21 Apr 1999 15:23:22 -0400 (EDT)
- 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 unspecified. 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 application-specific. 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. --Bede
Received on Wednesday, 21 April 1999 15:23:28 UTC