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

Hi Paul,


>No.  We do not need to allow any technology.

Why not?

>We must have a clear scope of work for this committee.

In what way does the position I'm expressing not lead to a clear scope of
work?  Our technology has been doing this for a year and a half, so
obviously the amount of work necessary to get this scheme to work is finite.

>We also need clear definitions of our terminology.  Biometrics are not
digital signatures.

This is your opinion, but I'm saying that we don't have the luxury of
excluding a technology because we don't like it.
These PenOp-like signatures are digital and they are certainly signatures in
a legal sense (see for example the works of the attorney Benjamin Wright).

However, this is debating about the example rather than the idea that the
example represents.

>XML is so flexible that it is easy to define opaque blobs that require
>arbitrary proprietary processing.  We are an open standards group and
>should strive to create a specification that promotes interoperable
>solutions.  We need to be clear on what specific technologies we recommend.
>
>Once again, I propose that "digital signatures" be defined in the scope of
>our committees to mean a public key cryptographic signature.

Firstly, why is an open standards group specifically recommending RSA?  It
hasn't left patent protection yet, and even when it does, the recommendation
would seem to favor a particular private company.  I know that it will also
be recommending other public key methods, but it will have to mention RSA.
It is simply not necessary to single out any specific technology to create a
signed XML standard.  It is only necessary to do this if you want to express
those signature in XML.

Secondly, isn't the IETF draft currently trying to consider other signing
modes besides public key cryptography?  Aren't they doing this because
symmetric keyed hashes are more appropriate to a particular application?
What other signature technologies that we currently can't envision will come
up in the future?  Biometric signatures were an example.

Thirdly, you haven't addressed my stated concern that if you write
signatures in XML, then certifying an implementation of signed XML cannot be
done unless the implementation contains the cryptographic layer.  This would
be esp. true of a W3C reference implementation, which must be completely
cross-platform and given in source code form.  What do you say to the
assertion that the W3C will not be able to distribute this reference
implementation outside of the U.S. and Canada?

There are two types of interoperability:  interoperability with technologies
and interoperability of technologies.

Your proposal sacrifices the ability of signed XML to interoperate with new
signing technologies.
What you appear to want is the ability to guarantee that a signature created
with any signed XML app will be able to verify with any other signed XML
app.  As an analogy, suppose we were creating a printing standard; this
would be like saying that we want printing implemetations to produce a
printer for those who don't have it.

I want interoperable signatures too, but if the signature engine (crypto
layer, biometric analysis software, etc.) is not available, then of course
we cannot verify the signature.  To defend your position, you must require
that the 'equipment' listed in the signature must always be present.  Hence,
every compliant signed XML application needs the crypto layer to make this
guarantee.

Whatever happened to loose coupling?  You want us to define a public key
cryptography standard, whereas I'd prefer it if we define an interface
standard that can connect to cryptographic technology built on cryptographic
standards defined by cryptography experts.  As a happy side effect, this
interface could also connect to other signing technologies besides public
key cryptography, like technologies that offer symmetric keyed hashes,
biometrics, and whatever else the future holds.


You support the interoperability of signature created by all compliant
signed XML technologies.  Here are the problems I've raised with your
position that you have not addressed:

1) Every compliant signed XML implementation has to include a cryptographic
layer.  Ultimately, the W3C reference implementation would need to include
the exact cryptographic functions, so it would not be distributable.

2) If you were to

Received on Wednesday, 21 April 1999 18:34:19 UTC