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

Perspective on signing XML 2

From: John Boyer <jboyer@uwi.com>
Date: Thu, 22 Apr 1999 12:12:48 -0700
Message-ID: <004201be8cf4$1cd1c150$9ccbf4cc@kuratowski.uwi.bc.ca>
To: <rdbrown@GlobeSet.com>
Cc: "Dsig group" <w3c-xml-sig-ws@w3.org>
Hi Richard,

Once again, thank you for your kind words and patience.  My letter to Phill
has more clarifying information that shows how to fit the types of things
you need to do inside of the type of thing I'm describing.  I hope it is
useful.  Further comments below.


>But, I have still a few concerns, which are nicely illustrated by your last
>email. Please consider the following that you have sent early on:
>> The relationship is that both have this form
>>     SignatureBlob = Sign(M, ...);
>>     Verified = Verify(M, SignatureBlob, ...);
>Though apparently a trivial interface, you have made use of '...' and in
>most circumstances this is where the problem lies. Every crypto engine
>requires a given set of parameters, which should be provided or at least
>referenced during the call to the engine. It appears that adopting your
>approach would only change the nature of the problem. Instead of argueing
>about encoding of the cryptographic parameters we will argue about the
>interface to the crypto engines. Being exhaustive in this matter will
>probably be as difficult as defining adequate encoding of the signature
>parameters. My feeling in that we have a broader experience with
>well-established crypto pratices than we have with packaged crypto-engines.

Firstly, you've hit the nail on the head in terms of our differing
experience base.  Many of the group have a lot of experience with
well-established crypto practices, whereas through XFDL my team has a lot
more experience with packaged crypto-engines.  Further, we did it this way
because we assumed that those packaging the crypto engines had the broader
experience with well-established crypto practices.

As for the problem simply being moved, yes I agree 100%.  However, my point
is that there is

Yes, I agree.  The problem gets moved.  But, there are numerous advantages
to moving it.
1) We're not trying to express the signature parameters in markup, so the
DTD and world-wide implementations won't have to change when we add new
signature technologies not currently envisioned.

2) This is more modularized; we can bring new signing technologies online
incrementally rather than trying to cover off all signing needs that people
might have all at once.

3) This layered approach means that we can connect our XML apps to existing
crypto packages  which organizations have already selected.  For example,
the Canadian Fed. Gov. has selected Entrust, period.  If you want to sell
something to them, it has to work with this package.  They won't want to use
the W3C's reference implementation code, and the W3C will not want to get
into the business of certifying as correct implementations that connect to
particular commercial packages.  Therefore, it is best to create a spec in
which one can be certified as a correct signed XML implementation because
correctness only means that you call the module of a given name with the
right parameters and the right message content.

4) By separating the cryptography from the act of signing, we can freely
distribute the reference implementation and it becomes the deployer's
responsibility to select and install signing technologies that are
commensurate with the needs of the target organization.  The companies that
produce the crypto layer have the export problems.  Whereas if the W3C
reference implementation (complete with source code) has to have a crypto
layer, it will be illegal for MIT to distribute it.

>I have also a few concerns regarding mandatory binding mechanics. As a
>matter of fact, verifying a signature value is usually insufficient. You
>need also to establish a secure link between the signer's "identification"
>and a trusted root (I do not necessarily mean a CA but rather some entry
>point of yours in a trusted framework). If the credentials (if any) remain
>opaque to the application logic, then you cannot establish that link. At
>most you know that some credential in the "signature blob" verifies the
>signature. You need more. The crypto engine should either externalize such
>credentials or be aware of the signification of "OriginatorInfo", which is
>contrary to your approach.

I agree with what you're saying, but not that it is contrary to my approach.
One of those many dots in the Verify() function is for parameters that allow
the return of engine-specific demographics of the signature.

There are not many pieces of information required to assess the value of a
signature.  The signer.  Some engine-specific info that says why we should
believe this was the signer (like the cert chain leading to the CA, or a
degree of biometric match for handwriting, retina scan, etc.), some
engine-specific info that specifies how much security was available (like
key size), the identity signing engine itself, and certain other
engine-specific info (like maybe the hash alg identifier).

The point is that the signing module decides how to fill in these five
fields.  These pieces of information represent the demographics that
populate the signature dialog box I mentioned in Phill's letter.

>Finally, whatever the approach we adopt, we will have to specify what is
>MANDATORY - either crypto algorithms or crypto engines - by default. In
>other words, specific frameworks such as IOTP, BIPS, or E-Check may elect
>specify whatever they want - interoperability is guaranteed within the
>confine of these frameworks. But this is not duable in general. Assume that
>Netscape adopts PKCS#7 while Microsoft adopts CMS-V3 in their respective
>browsers. Though similar in many respects, these two standards are not
>compatible (CMS being broader than PKCS#7). One more time, we will put the
>burden on the server side that will have to deal with these discrepencies -
>and this will be insufficient for three-party exchanges.

It's true that the signatures themselves will only be as interoperable as
the underlying signing modules allow them to be.  Currently, we have
interoperability between Netscape, Microsoft and Entrust digital signatures.
This is because they all rely on the same (non-XML) standards.

What you're saying is that creating yet another standard for representing
signatures in XML markup will solve this problem when in fact it will only
solve the problem to the extent that all of these manufacturers agree to
support the new XML markup for signatures.  So, whether we convince all of
these vendors to adopt the XML standard or some other binary standard is
irrelevant.  If they all run with the same standard, then signatures will be
interoperable.  Whichever standard they choose in the long run, we can still
sign XML with the method I'm talking about because the method does not care
about what's in the blob.

I'm not saying it wouldn't be valuable to have signatures in XML for certain
types of signatures.  I am saying that it is possible to write a signed XML
spec without writing a new crypto standard for how signatures themselves
should be represented.

Maybe we need two groups.  I definitely think it would be easy to add the
XML signature ideas into the framework that I'm talking about, as I stated
in Phill's letter, because it is possible to look at the XML signature
implementation as another packaged crypto engine.

There are downsides to expressing cryptographic signatures in XML, and I'm
hoping that we can sidestep the difficulties by taking this broader, staged
approach.  We could specify how signature engines work and get that out by
the year 2000, with the XML signature spec working concurrently but coming
out some time later.  Again, here are the problems:

1) The DTD is required for name spacifying the elements.  As new
technologies with unenvisioned needs are created, the spec, the DTD, the
reference implementation, and all compliant implementations worldwide will
have to be changed.

2) The reference implementation will need to have all crypto algorithms
suggested by the markup in order to demonstrate full compliance with the
spec.  MIT will not be able to distribute.  Moreover, all companies creating
compliant implementations will have those lousy export restrictions imposed.

These are reasons why I think it will take a standard for expressing
signatures in XML significantly longer to finish.  When it is finished, it
can be plugged in as a signing module and hopefully everyone will adopt it,
but we can't count on that.  Further, I'd prefer it if we had a standard for
signing XML much sooner.

John Boyer
Software Development Manager
UWI.Com -- The Internet Forms Company
Received on Thursday, 22 April 1999 15:08:51 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:44:59 UTC