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

>>>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?
>
>You are confusing technologies with required functionality (biometrics
>versus data origin authentication).

Technologies provide functionality, so it is not possible to confuse the
two.
You want to describe what signature functionality is required, but that
means you will have to build a technology to support it.  I am saying that
the functionality for signatures is already defined by the cryptography
experts, and they have already built the technology to support it.
It is therefore possible for us to define the functionality of signed XML to
be that it interfaces to modules that provide Sign() and Verify() functions,
and it is then possible for us to build a technology to support just that
functionality, leaving the details of distributing signature modules to
those who create signature modules.

>
>>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.
>
>I don't know much about PenOp.  If it uses public key techniques then
>Ibelive it would fit in our framework as a proprietary signature mechanism.
>If it is based on a key-hash, it will fit in our framework as a proprietary
>key-hash mechanism.  If it is none of the above, you can still field your
>proprietary product by using a variety of XML extension approaches.  It
>just won't be a standard.

True and this is one possible direction.  The position I'm articulating is
that it doesn't have to be the case.  A company can produce a proprietary
signature technology, then offer the ability to sign with that technology to
the XML world by simply writing a module that conforms to a signed XML
module interface.

This idea has precedent in such frameworks as the Microsoft CryptoAPI, which
provides a cryptographic interface that allows application developers to
call upon crypto functions, and other

This view of signed XML is very much like the CryptoAPI design.  This is the
right design because it allows the signature equipment to be selected at the
time of deployment by the company deploying the technology.

>
>>>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?
>
>RSA, DSA, ECDSA, ECNR are all types of algorithsm taht should be supported
>by our specification since each is a assymetric cryptographic technology
>that has comparable functionaal characteristics.  RSA is patented, so we
>would be better served by DSA or ECDSA.

A position which removes RSA support from the signed XML standard will not
get much support.

>
>>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?
>
>The IETF draft is one proposal.  As I've stated before, our committee seems
>to have requirements to support a keyed-hash, I'm just reluctant to call
>this technique a "digital signature". Tags in the XML should clearly
>identify the protection provide by signatures versus a keyed hash.
>

OK, this is where we agree to disagree because I think that if they can fit
it into a Sign() and Verify() paradigm, then they should be able to do it.
I think they should write it as a separate specification from signed XML,
but I think signed XML should support this method even though it may not be
as secure as public key cryptography.

>
>>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?
>
>This is always the case with cryptographic technologies is not relevant to
>our other discussion points.  There are a variety of ways to sovle this
>problem.  Perhaps a university in Europe would development a reference
>implementation ;-)

That's a decent proposal, but the W3C still wouldn't be distributing the
W3C's reference implementation.
Once again, I am guilty of using an example to make the point of a more
general problem, which is that every compliant application would have the
same distribution problems.  Software providers cannot all have their
software developed and distributed by European universities.

>
><<clip ...>>
>>Hence,
>>every compliant signed XML application needs the crypto layer to make this
>>guarantee.
>
>Yes.

Good, now we have the meat of the issue.  Do we integrate signature
technologies or do we build our own?  It is not necessary to build our own.
Some may prefer to build our own, and the group may well decide to do it
this way.  But still, it is a preference and not a requirement.  XFDL's
signature paradigm would be a counterexample to any claim that one cannot
sign XML without building one's own crypto layer.

>Your one argument for biometrics is:
>>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.
>
>Propretary biometric techniques will not solve the interoperability
>problems or support the creation of reference implementations.
>
>Cryptographic techniques are available worldwide.

No, that is not my argument for biometrics.  That is my argument against
expressing signatures in XML as opposed to signing XML by specifying an
interface for signature modules.  The happy side effect of my approach is
that diverse technologies like biometrics can also be supported.

Finally, let me reiterate once again that biometrics are only an example of
diverse technology that could be supported by a standard we create now if
such a standard has the properties that I've been talking about in these
emails.

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company
jboyer@uwi.com

>
>
>Paul
>
>
>
>
>
>"John Boyer" <jboyer@uwi.com> on 04/21/99 03:38:19 PM
>
>To:   Paul Lambert/Certicom
>cc:   "Dsig group" <w3c-xml-sig-ws@w3.org>
>Subject:  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 20:10:48 UTC