Bodo Moeller wrote:
Dr Stephen Henson
<shenson(_at_)drh-consultancy(_dot_)demon(_dot_)co(_dot_)uk>:
It's not simply a "provision" to do so, in fact the server is even
obliged to send the list. The relevant definition (from
draft-ietf-tls-protocol-06.txt, but it's the same in the early SSL 3.0
specs) is
struct {
ClientCertificateType certificate_types<1..2^8-1>;
DistinguishedName certificate_authorities<3..2^16-1>;
} CertificateRequest;
<3..2^16-1> means that the list of certification authorities is at
least 3 octets, at most 2^16-1 octets long -- i.e. may not be empty.
I think that SSLeay will send an empty list when
SSL_CTX_set_client_CA_list has not been called, but it is asked to
demand client certificates anyway. SSLeay-based software that
behaves in that way is in violation of the specification.
Yes it does violate the SSL spec in this sense but nevertheless
Communicator versions before 4.06 permitted this and client auth worked
fine with an empty list. MSIE and Communicator 4.06 and later offer a
choice from the supplied list and give rather misleading behaviour when
no match is taken: MSIE presents an empty list to choose from and
Communicator just says you have no client certificates.
Also note that your wording "There is a provision to just send the
acceptable issuer names not just as part of the server chain" is
misleading. The certificates in the server chain may have nothing to
do with the CAs the server accepts for clients. For example, the
server's certificate might be issued by one of the large commercial
CAs (Verisign, Thawte, ...), but the only accepted client certs might
be those issued be the webmaster's own CA (perhaps used in order to
protect /server-stat and access to the logfiles from the public).
This has to be taken into the context of the original query where the
sender was assuming that the acceptable CA list was just communicated by
including the CAs as part of the server CA chain.
Steve.
--
Dr Stephen N. Henson. UK based freelance Cryptographic Consultant.
For info see homepage at http://www.drh-consultancy.demon.co.uk/
Email: shenson(_at_)drh-consultancy(_dot_)demon(_dot_)co(_dot_)uk
PGP key: via homepage.