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 Thursday, 25 January 2001 18:43:59 UTC