Perspective on signing XML 1

>> However, for the record, most of you seem to be missing the
>> point.  You can
>> agree or disagree or argue about the merits of this technology
>> all you like.
>> Unfortunately the point is that you shouldn't be arguing about the
>> technology at all.  We need to let the technology provide the security.
>
>You can call me an arrogant @#&% if you like but I don't think that
>Bede, myself and others are arguing from ignorance of the technology
>here.

You have my sincere apologies.  I did not mean to imply this.  Actually,
what I was saying is that many are coming from a very heavy amount of
experience with crypto signature technologies.  Although I'm conversant with
the math that supports RSA as a result of my graduate studies, I don't know
as much about all of the details of the prior standardization efforts.  The
approach we've taken is to leverage the experiences of persons such as
yourself and Bede by creating a model which allows straightforward
integration with new signing technologies as they come out.  So, what I was
saying was that I wasn't being understood because I was *not* hitting the
signing problem at the deep and heavy crypto level.  Richard's email
precisely identifies our different perspectives.

It is interesting to note that you ask below what I mean by "Let the
technology provide the security" because understanding that remark
essentially means understanding this different angle I'm presenting.  This
is only one possible path the group could take, and even if the group
decides against, I am still grateful that you've take the time to consider
this point of view.

In part, this model was inspired by the design of Microsoft Crypto API and
Netscape Cryptoki pluggable cryptographic architectures.  Entrust
cryptography and PenOp came later, but it is, to me, a good sign, that we
were able to incorporate these diverse new technologies in two to four
person weeks apiece.

It would be useful if we created a spec that allowed us to incorporate new
technologies without changing the core signed XML specification.  We can
define new valid signature engine strings as we go along, but those are
recognized by the DTD as PCDATA.  We adopted the MIME type with parameters
as the way of specifying parameters to a signature engine.  We then write a
small spec for each new technology to describe what parameters it needs.

>'Letting the technology provide the security'??? I have no idea
>what the statement means.

Let's run through an XFDL example.  Won't take long.
A user presses a sign button.  A dialog comes up; it is empty at first.
User presses the Sign button.  Based on the signature engine specification,
we go to the right signing module and ask it to give us all signing
identities available for that person.  It does.  We present the list for the
user to pick from (or short circuit the list if only one identity is
returned).  The user picks his/her identity-du-jour, and we then call the
signing module's SignMessage() function, passing it some portion or all of
the XFDL form.  The signature filter is used to cut out pieces of the form
that should not be signed.

SignMessage() returns a blob specific to the design of the signing engine
with which we've integrated.  We base 64 encode that and stick it into the
character content of a subelement of our signature element.

Immediately after that, we run the VerifyMessage().  The base64 block is
decoded and passed to the function along with the message (part or all of
the XFDL form).  This is mostly a matter of keeping the interface as simple
as possible.  Verify is expected to do the signature check, but also return
certain demographic information about the signature (like who signed, for
example).  We use the demographic data to populate the dialog that came up
when they started.

From this model you can see that not once did I say enough about the signing
module for us to decide how secure it was.  The signing module itself
provides the security.  Each of the three fundamental signing technologies
we've been discussing so far (public key, keyed hash, symmetric encrypted
biometric) have varying levels of security that they offer.  The signing
technology is providing the security.

The main thing we did was put together a sequence of operations such that we
didn't introduce any security holes in our use of the technology.  For
example, making sure you sign the signature engine parameters (like hash
algorithm, message filter, etc.)

This model is actually even more extensible than one might think.  For
example, we have an integration to Microsoft CryptoAPI (one could say the
same things about Netscape).  CryptoAPI itself allows for pluggable
security, letting the deployer of the security framework choose how much
security is required.  For example, some of our deployments use the software
RSA enhanced DLL for signing, while others use a DataKey smartcard.

Are the signatures interoperable?  Yes.  We can create a signature with a
DataKey smartcard under CryptoAPI, then send the result to a machine that
doesn't have cryptoAPI, and verify the signature under Netscape.  We have
interoperability to the extent that the signature module vendors follow the
going cryptographic standards.

If the W3C wants to create an XML standard for the representation of digital
signatures, I'm claiming that this is a cryptographic standard.  It can be
rolled into one spec, but from a modularity-layered abstraction-loose
coupling point of view as well as a practical point of view, it makes sense
to tackle that separately.

>As Don points out attaching Biometrics to the message envelope results
>in a system 'about as secure as copy protection', while I agree that
>people want to do that and should be acomodated I don't think that it
>is a good idea for the group to put itself in a position where its
>statements will be used in marketing litterature to imply endorsement.
>

Oh, quite the opposite.  What I'm talking about is complete abstraction.  We
don't have to say squat about the qualities of the underlying signature
engines.  Organizations set their own policies about security.  What I'm
hoping for is a spec whose implementation makes it possible for me to
integrate with the security system selected by the organization.  Numerous
standard security systems exist now.  More will emerge in the future.  When
they do, I need to write a small spec and a new DLL.  No new release of the
core software.

>
>The best use for biometrics is to gate access to a private key which
>is in turn used for creation of a digital signature.
>
>All else IMHO is a rat-hole. Which is why I didn't really want to go
>into the subject. I believe that the requirements of PKI are a strict
>superset of the requirements of biometrics.
>

Not really a superset considering that the single biggest reason for
biometrics is to avoid setting up a PKI.  In some cases, such as walk-in
bank business, it doesn't make sense to have a PKI.

But this is really beside the point.  The point is that there are and will
be diverse signature technologies going forward.  It is possible to create a
signed XML standard that can accommodate diverse new technologies without
change the dsig namespace DTD, without changing the reference
implementation, and without every compliant application having to release a
software upgrade.

Finally, consider what happens if the W3C then wants to consider writing a
signing module that expresses everything in XML.  This is a new emerging
cryptographic standard, whose implementation will provide a new signing
technology.

Remember that base 64 blob I told you about.  If we simply add an encoding
attribute to the element, we could control whether signed XML stores the
result of SignMessage() in the raw or in base 64.  Your new crypto standard
would obviously prefer no encoding.

Do you see how what you're talking about fits wonderfully into what I'm
talking about?  It means we can cover the diversity of technologies right
away, and tackle the complexities of various XML signature types separately.
For example, the current IETF draft talks about two distinctly different
signature types.  These could be done as separate specifications if it makes
sense (and many of you would be better judges of that than I would).

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

Received on Thursday, 22 April 1999 15:08:52 UTC