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

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

Yes, folks are definitely missing the issue.  It doesn't matter what anyone
things about this particular technology.  It conforms to an interface that
includes Sign() and Verify() and fills a certain need to sign XML.  We want
a framework that signs XML.  It is possible to create one that accommodates
all technologies including this one.  It is up to the creator of this
technology to convince clients that it offers a viable signature technology
given the parameters of the intended deployment.  It is up to us to make it
possible for signature technologies to be incorporated into XML without
having to request that the W3C change the spec.

PenOp is an example.  The point is that we cannot anticipate all possible
signing technologies.  The material in the IETF draft already shows that the
creators of PKCS#7 and other similar standards did not anticipate all
signing technologies.  I'm not convinced they were even trying to do this.
RSA wanted to create a standard for its  own technology and rightly placed
the burden of other standards into the hands of those that would create
those new technologies.  We also cannot anticipate what's coming, so we
can't write a markup that encompasses all of it.

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

Reminder:  PenOp is only an example.  Don't pick on the specifics of the
example or you'll lose site of the fact that I only used it as a concrete
example of the fact that we can't anticipate all technologies going forward.

For what it's worth though, here are the differences.  PenOp provides an API
that has a sign function. I give it a message, it gives me back a blob.
That blob is encrypted.  Inside the blob is the hash AND the biometrics.
Current signature technologies only encrypt the hash, so that's one
difference.  More importantly, though, PenOp perceives that they can only
make an argument for a secure product if they return this encrypted blob.
That's the interface, period.  We either say that we will or will not allow
this type of technology to sign XML.

There is no good reason to disallow this technology.  XFDL shows precisely
how even this technology can be incorporated.

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

See above.

>For the sake of ensuring interoperability, we need to specify a (set
>of) "MUST" algorithms for signing, none of which should be proprietary.

Firstly, if you are saying that we need to have "MUST" algorithms for
signing, then a compliant implementation will need to provide those
algorithms.  Will the W3C be able to distribute a reference implementation?
No.

Furthermore, why can't they be proprietary?  It is customary in cryptography
circles to publicize the details of an algorithm because it is not
considered cryptographically secure if knowledge of the algorithm breaks the
security.  But we're not talking about cryptographic security.  We're
talking about signing XML.

If the underlying signature technology offers cryptographic strength
signature, then great.  In my opinion, handwritten signature cannot offer
cryptographic strength security by themselves.  But do they perform a
valuable service that is at least as hard as paper signatures to break?
Could be.  Does it matter?  No.  What matters is that it has an interface
that includes a sign function and a verify function.  The level of security
offered is up to the signing module itself.  So, can the algorithms be
proprietary?  Sure they could because all we need to care about is that the
blob coming out of Sign() can go back into Verify().

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

Yes, and we can accommodate them all by not trying to express signature in
XML.

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

I don't think that's a problem.  If the sign block contains code, and the
verify block runs that code, then that is a design issue of the underlying
signature technology.  It's weird, but a black box is a black box.  When you
have a data structure that declares that SHA-1 should be used, how is that
not code?  Your data structure is a "declarative" program in that "commands"
like SHA-1 imply certain semantics.

Received on Wednesday, 21 April 1999 16:27:22 UTC