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

Re: Blob free zone - was Re: Fw: XML versus ASN.1/DER blob

From: John Boyer <jboyer@uwi.com>
Date: Wed, 21 Apr 1999 17:14:49 -0700
Message-ID: <00de01be8c55$235f4eb0$9ccbf4cc@kuratowski.uwi.bc.ca>
To: "Paul Lambert" <plambert@certicom.com>
Cc: "Dsig group" <w3c-xml-sig-ws@w3.org>
>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.

We can put limits, but it is not necessary to do so.  If the requirements
are that modules provide a Sign() and Verify() function, then all can be
accommodated.

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

The biometric token *is* the signature.  It is not part of the solution.
The people who want biometric signatures don't want to set up a PKI.  If it
were practical for them to do this, they wouldn't choose the biometric
approach.

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

Then you will have only certified that the DSA portion of your markup is
working.  If you have tags, atributes, keywords, etc. that declare the use
of technologies like RSA, then you can't say that the reference
implementation completely implements the spec until you test everything in
the spec.  If the spec explicitly supports RSA, then so should the reference
implementation.

Further, the U.S. export restrictions even apply to code that you get from
somewhere else.

>
>>
>>Furthermore, why can't they be proprietary?
>
>Because we are an open standards committee fielding solutions to promote
>interoperable implementations.

The implementations will be interoperable under this proposal.  A given
signature may not be verifiable if the verifier does not have the specified
signature technology, but every implementation will do the same thing in
that it will encounter a signature, query whether it has that engine, then
use that engine if available.

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

We have an integration to a biometric technology, specifically PenOp.  We do
not develop this technology nor do we care to know what it does internally.
The clients who buy our forms make their own security decisions, and some of
them decide that they want pen-based signatures.  In fact our integration
came about because certain potential clients liked our forms but would not
buy our product unless it had the pen support that they wanted.

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

Again it is only your opinion that signed XML must be based on cryptography.
We don't even have a signed XML working group, so how can we say for sure
what signed XML is based on?  As soon as we have a working group, we will
need to have both sides of this debate produce a clear position statement,
then put it to a vote.
Alternately, we could seek comment from the business community that this
technology will be trying to service.

Even with these measures, we still have the presumption that the voters and
commenters might be able to envision new technology.

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

I don't think that a signature module will get very much use if it does not
offer these things, so our specifying this as a requirement is superfluous.
However, we can still make a requirement that only modules that provide
these features can be considered compliant.  Any organization which claims
to be standard compliant but whose signature modules does not offer these
features would be subject to litigation.  We can't write a spec that
prevents people from lying about their software.

>
>>What matters is that it has an interface
>>that includes a sign function and a verify function.
>
>No, this does not matter at all.

Any signature technology must by definition have the logical equivalent of a
Sign() and Verify().  It is absurd to say that it does not matter whether
they have these functions since without this ability you can either not sign
or not verify.

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

The blob may have properties, but those properties are likely to vary based
on type of signature technology.  For example, symmetric keyed hashes don't
have the same properties.  What properties will signature technologies of
the next decade have?

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

XFDL currently simply base-64 encodes the binary blob coming out of the
Sign() function.
The IETF draft already talks about using base-64 for some of the little
binary pieces.

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

This is actually a healthy debate to have.  Obviously I have a 'most
favorable' position in mind, but even if another good solution is adopted,
it is important that we have a well-articulated reasoning for the adopted
solution.  These emails have uncovered that many things people thought were
necessary are not.  They might be 'preferable', in which case we have to
have a reason why we prefer a particular solution.

So, I appreciate your patience on this matter.

As for precise definitions and scope, I do not see how my position lacks
precision.  The definition of signature is from the legal literature.  The
XFDL defines what it takes to represent a digital signature to such an
extent that we have numerous deployments, including two in the Pentagon,
using diverse signature technologies.   The interface to a signature module
is specified in English but also described with the precision of the C
language.  That interface has integrations to Microsoft CryptoAPI, Entrust,
Netscape and PenOp.  As far as I know, no other organization besides
Netscape can use Netscape's certificates, which is further evidence of a
highly defined abstract interface.  Moreover, generic interfaces like
CryptoAPI, Netscape and Entrust support plugging in crypographic layers that
provide different algorithms.  Despite this, all of these signatures are
represented in the same way in XFDL.  Therefore, having done it already, I
think there is evidence that it is possible to be precise in our definitions
and still support the position I'm talking about.

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company
jboyer@uwi.com
Received on Wednesday, 21 April 1999 20:10:47 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 11:28:04 EDT