Re: Multiple IssuerSerial/SubjectName/SKI in an X509Data

     I am sorry not to have responded to this before now.  The rule I
proposed before for the inclusion of X509Certificate elements was that all
such elements must either certify the public key of the key pair used to
sign the message or that they must be certificates for the issuer of at
least one other included X509Certificate.  This allows a "means of
identifying the
signer when presented only a group of X509Certificate elements other than
trial and error", in that one can eliminate issuer certificates by matching
issuer names to subject names.  Is there much support for the idea that
picking out the signer certificate is a real problem?
     A relaxation of the above rule to permit elements which certify an
issuer identified through the X509IssuerSerial or X509IssuerName elements
is also obviously reasonable, and so MIGHT be a similar relaxation for the
issuer of an X509CRL.  Does anybody know why a certificate which is not the
issuer of any of these would be reasonable to include as long as there are
no elements beyond the current ones?

          Tom Gindin

          Tom Gindin

"Carl Wallace" <cwallace@erols.com>@w3.org on 01/25/2001 06:44:33 PM

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


To:   "Rich Salz" <rsalz@caveosystems.com>, "TAMURA Kent"
      <kent@trl.ibm.co.jp>
cc:   <w3c-ietf-xmldsig@w3.org>
Subject:  Re: Multiple IssuerSerial/SubjectName/SKI in an X509Data



> > The latest specification allows multiple X509IssuerSerial
> > elements, multiple X509SubjectName elements and multiple X509SKI
> > elements in *an* X509Data.  I think all X509IssuerSerial
> > elements must have the same content because they represent
> > issuer information of the same certificate.  It this right?
>
> No.  More than one CA can sign the same certificate, so it is possible

^key?
> to have multiple "paths" from a given cert up to a trust anchor.
>
> Certificate path verification, validation, etc., are tough issues; you
> might want to take a look at the draft-ietf-pkix-new-part1-03.txt.
>
>

This thread raises a couple of points in the spec regarding X509Data.

1) In describing X509Data the spec states that the content of X509Data is
"at least one element, from the following set of element types; any of
these
may appear together or more than once iff each instance describes the same
certificate".  This is inconsistent with the practice of including
certificates from a path, a bag of certs, crls, etc. unless such blobs are
considered to be "describing" the signer's certificate.  The spec is clear
that when multiple certificates, and presumably other forms of X509Data,
are
present at least one must describe a cert that contains the public key used
to verify the signature.

2) The above exchange between Tamura and Salz is based on the notion that
X509Data can contain certificates issued to entities other than the signer
of the certificate, a notion that the spec makes clear by way of a cert
chain example.  Further, it suggests that certificates other than the
signer's cert may be identified by elements other than X509Certificate and
that a single X509Data element can contain information related to multiple
paths.  Thus a single X509Data element can contain a complex set of
information but provides no means of identifying which element(s)
corresponds to the signer.  It would be nice to have a means of determining
the signer of the message other than trial and error, especially if certs
for entities other than the signer can be identified instead of directly
included.

To address these two issues the text in 1) could be revised to permit the
use of X509Certificate elements for including different certificates in a
single X509Data element and to restrict the use of X509IssuerSerial,
X509SKI
and X509SubjectName to identify the message signer's certificate only, in
which case there is no need to permit multiples of these three types.  This
would still leave no means of identifying the signer when presented only a
group of X509Certificate elements other than trial and error but it would
be
an improvement.

Received on Tuesday, 30 January 2001 12:24:11 UTC