RE: Questions/Comments for the current draft.

Thanks, Tom!

That is the correct interpretation. KeyValue is the mandatory default
for interoperability. Any conformant verifier implementation must
support it. 


-----Original Message-----
From: []
Sent: Wednesday, July 12, 2000 1:53 PM
To: Kevin Regan
Cc: Barb Fox; Ken Goldman;
Subject: RE: Questions/Comments for the current draft.

     Don't look now, but the KeyValue is described as mandatory to
implement.  I don't think that that means that if a signer puts in an
X509Data they also will put in a KeyValue, nor even that they're

          Tom Gindin

Kevin Regan <> on 07/12/2000 02:02:51 PM

Sent by:

To:   Barb Fox <>
cc:   Ken Goldman <>,
Subject:  RE: Questions/Comments for the current draft.

Ok, I did not see that the KeyValue was mandatory if a KeyInfo
was present.  In this case, it is unambiguous as to what the
authentication key is.


On Wed, 12 Jul 2000, Barb Fox wrote:

> Ken:
> Looking at a broad range of applications, the wg decided that KeyInfo
> needed to be optional, but when present, could specify a number of
> different types including X.509 certificates.  Further, we made the
> decision that XMLDsig signature verification should not require other
> than XML tools -- which includes ASN.1.
> If an application chooses to use an X.509 certificate as the only form
> of KeyInfo supporting a signature, then it probably also presumes that
> all verifiers will be able to process it. That's not a safe bet for
> small XML-capable devices, which is why we chose KeyValue as mandatory
> to implement if KeyInfo is specified.
> --Barbara Fox
> Microsoft
> -----Original Message-----
> From: Ken Goldman [
> <> ]
> Sent: Wednesday, July 12, 2000 7:02 AM
> To:
> Subject: Re: Questions/Comments for the current draft.
> 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 <>
> >
> > 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   914-784-7646

Received on Wednesday, 12 July 2000 18:45:21 UTC