W3C home > Mailing lists > Public > w3c-ietf-xmldsig@w3.org > July to September 2000

Re: Questions/Comments for the current draft.

From: Ken Goldman <kgold@watson.ibm.com>
Date: Wed, 12 Jul 2000 10:01:44 -0400
Message-Id: <200007121401.KAA36130@alpha.watson.ibm.com>
To: w3c-ietf-xmldsig@w3.org
I agree.  My reaction when reading the DSIG specification for the
first time was "how do I show a certificate chain."

I'd sure like to see a certificate chain explicitely part of DSIG.
But I've already been told that this is considered "outside DSIG, part
of the application."

My suspicion is that, in the real world, crypto verification pushed up
to the application will be crypto verification ignored.  The average
application developer might make an API call to verify a document.
Once the generic DSIG verifier comes back "true", the program goes on
"fat, dumb, and happy" not knowing that the signature was verified
against a forged public key.

The least DSIG KeyInfo could do is explicitly warn the reader.  As the
specification reads now, the goal of flexibility is reached by being
silent on a very important security issue.

> Date: Tue, 11 Jul 2000 15:26:07 -0700
> From: Kevin Regan <kevinr@valicert.com>
> Would it make sense to somehow delineate different chains within the
> KeyInfo element? Rather than just having a hodgepodge of certificate
> entries, would it be possible to group them in something like a
> <X509CertificateChain> element (in the correct order)?  As a user
> (and implementer) of XML Signatures, it would be great to have a
> well-defined way of representing the certificates/keys/certificate
> chains that I would use to authenticate the signature.  The KeyInfo
> field is very flexible, but maybe a little less flexibility would go
> a long way here... :-)

Ken Goldman   kgold@watson.ibm.com   914-784-7646
Received on Wednesday, 12 July 2000 10:01:46 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:21:34 UTC