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. 

--Barb 


-----Original Message-----
From: tgindin@us.ibm.com [mailto:tgindin@us.ibm.com]
Sent: Wednesday, July 12, 2000 1:53 PM
To: Kevin Regan
Cc: Barb Fox; Ken Goldman; w3c-ietf-xmldsig@w3.org
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
supposed
to.

          Tom Gindin

Kevin Regan <kevinr@valicert.com>@w3.org on 07/12/2000 02:02:51 PM

Sent by:  w3c-ietf-xmldsig-request@w3.org


To:   Barb Fox <bfox@Exchange.Microsoft.com>
cc:   Ken Goldman <kgold@watson.ibm.com>, w3c-ietf-xmldsig@w3.org
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.

--Kevin


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
many
> 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 [ mailto:kgold@watson.ibm.com
> <mailto:kgold@watson.ibm.com> ]
> Sent: Wednesday, July 12, 2000 7:02 AM
> To: w3c-ietf-xmldsig@w3.org
> 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 <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
>
>