RE: Questions/Comments for the current draft.

I do see your point that different chains could share the
same certificate.  In this event, having to duplicate the
information might not be ideal...

--Kevin

-----Original Message-----
From: tgindin@us.ibm.com [mailto:tgindin@us.ibm.com]
Sent: Tuesday, July 11, 2000 4:04 PM
To: Kevin Regan
Cc: Brian LaMacchia; 'Yoshiaki KAWATSURA'; w3c-ietf-xmldsig@w3.org
Subject: RE: Questions/Comments for the current draft.


     It might well make sense, and it would surely be convenient for
validation software, but is it really necessary?  After all, by matching
issuer names with subject names and AKI extensions with SKI ones (or
performing a signature verification if the KI extensions are missing),
one
can tell for any two certificates in the set whether one was the issuer
of
the other or not, and thus construct the intended set of chains,
especially
since we know which were the actual signing certificates.
     The resulting structure could have some loops at higher levels,
which
might be considered sufficient reason for such a change.  The simplest
loop
would have 2 EE certificates from different issuers but with the same
key,
and with the issuers of these certificates mutually cross-certifying.
Even
with only one EE certificate, a similar loop can be constructed if the
issuer of that certificate had CA certificates issued by two
higher-level
CA's which were mutually cross-certifying.

          Tom Gindin

Kevin Regan <kevinr@valicert.com> on 07/11/2000 06:26:07 PM

To:   Tom Gindin/Watson/IBM@IBMUS, Brian LaMacchia <bal@microsoft.com>
cc:   "'Yoshiaki KAWATSURA'" <kawatura@bisd.hitachi.co.jp>,
      w3c-ietf-xmldsig@w3.org
Subject:  RE: Questions/Comments for the current draft.



Hi,

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... :-)

Sincerely,
Kevin Regan
kevinr@valicert.com

-----Original Message-----
From: tgindin@us.ibm.com [mailto:tgindin@us.ibm.com]
Sent: Tuesday, July 11, 2000 3:19 PM
To: Brian LaMacchia
Cc: 'Yoshiaki KAWATSURA'; w3c-ietf-xmldsig@w3.org
Subject: RE: Questions/Comments for the current draft.


     Well, your intent is now clear.  Since this is a reasonable
position,
I propose that a minor edit be made to section 4.4.4 to make it clear.
Before the sentence in 4.4.4 which begins "for example", we should add
the
following sentence: A certificate is related to the signing key if it is
either a certificate for that key (normally an end entity certificate)
or a
CA certificate in a certificate chain for one of the certificates for
that
key, and multiple certificates (either EE or CA certificates) for a
specific key are permitted in a single KeyInfo element.  Further
comments
below.

          Tom Gindin

(snip)