Blob free zone - was 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 are not developing a API specification.  The committee is developing a
signaling specification that describes syntax and processing.

Need ... this is a debatable requirement.  I concede that we should design
a framework that could incorporate biometric information as an attribute.
There is no requirement to allow an opaque blob consisting of biometric
information to be carried in an XML digital signature field that is called
"signature".

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

No!  Interoperablity is one of the primary purposes of standards.  XML is
so flexible that proprietary mechanisms can always be defined that would
overload the intended meaning of any specific field.

>
>PenOp is an example.  The point is that we cannot anticipate all possible
>signing technologies.

True, but we can limit the possible extensions to techniques that have
similar functional characteristics.  New public key cryptographic
techniques should be allowed.  A digital signature that binds biometric
information might be viable, but it should meet a consistent set of
requirements for the desired functionality.

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

There is no reason to specifically include this technology.  You will also
always be able to find proprietary ways to support this technology.  I've
suggested a couple of ways that we could also give incorporate biometric
information, not as a signature, but as part of our overall solution.

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

Why not?  I propose we use DSA and/or ECDSA algorithms that are in the
public domain and available in source code from sites in Europe.  Do you
have reasons other than patents or export restrictions that the W3C will
not be able to distribute reference implementations?

>
>Furthermore, why can't they be proprietary?

Because we are an open standards committee fielding solutions to promote
interoperable implementations.

I assume that you must have a biometric technology that you are selling in
your product.  Is this true?

Proprietary solutions are always possible and need not be discussed as part
of the standards process.

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

I believe you are missing the point here...  Signed XML is based on
cryptographic techniques.  The specification need to be open, not for
security reasons, but because we are an open standards committee

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

Yes, it does matter.  Our requirements should include:
- support for data origin authentication
- support data integrity

>What matters is that it has an interface
>that includes a sign function and a verify function.

No, this does not matter at all.

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

The blob must have properties that we can describe ... like the ability for
only a single unique entity (aka key holder) to create the blob coming out
of Sign().

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

So are you proposing some other syntax?  Perhaps ASN.1? Anything parseable
in this XML committee needs to be in XML so I do not understand your
proposal.

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

I believe we are flogging this horse to death.  I am trying to be
supportive of a design that might incorporate biometric data, but insist
that as a committe we be prexise in our definitions and scope of
activities.


Paul

Received on Wednesday, 21 April 1999 18:43:32 UTC