I'm looking at the TLS 1.1
Internet-Draft and it reads:
7.4.4. Certificate request
When this message will be sent:
A non-anonymous server can optionally request a certificate from
the client, if appropriate for the selected cipher suite. This
message, if sent, will immediately follow the Server Key Exchange
message (if it is sent; otherwise, the Server Certificate
message).
Structure of this message:
enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
rsa_ephemeral_dh_RESERVED(5), dss_ephemeral_dh_RESERVED(6), |
fortezza_dms_RESERVED(20), |
(255)
} ClientCertificateType;
opaque DistinguishedName<1..2^16-1>;
struct {
ClientCertificateType certificate_types<1..2^8-1>;
DistinguishedName certificate_authorities<0..2^16-1>; |
} CertificateRequest;
certificate_types
This field is a list of the types of certificates requested, |
sorted in order of the server's preference. |
certificate_authorities
A list of the distinguished names of acceptable certificate
authorities. These distinguished names may specify a desired
distinguished name for a root CA or for a subordinate CA;
thus, this message can be used both to describe known roots |
and a desired authorization space. If the |
certificate_authorities list is empty then the client MAY |
send any certificate of the appropriate |
ClientCertificateType, unless there is some external |
arrangement to the contrary. |
Reading
through the minutes and mailing lists of IETF TLS Working Group, it is
clear that this change was made because the vast majority of implementors
had already been allowing a certificate request to be sent without
a
certificate authority name being specified. In TLS 1.0, according
to the spec
there must be at least one certificate_authority specified in
the list.
To be compliant with TLS 1.0 you must call
SSL_set_client_CA_list() with
at least one certificate authority.
However, the general consensus as indicated
in TLS 1.1 is that the
specification of a certificate authority should not be
required.
TLS
1.1 has passed last call and is currently being reviewed by the
IESG.
Jeffrey Altman
Erik Tkal wrote:
Jeff,
Look in s3_srvr.c -
ssl3_send_certificate_request calls SSL_get_client_CA_list to get the
stack of CA names (assumedly set by other code having called
SSL_set_client_CA_list). However, if the server side code has not set this
then the stack is empty, so the code ends up setting the 2-byte length field
to 0x0000 and appending no further data to the message.
So the questions that remain
are:
1) Is this ok and should clients be required to
handle this, and if so where is this documented?
2) If it is required for the server implementation
to call SSL_set_client_CA_list, should an error be surfaced at some
point when this is detected?
3) If a server implementation is to call
SSL_set_client_CA_list how should it specify that it does not care what the
client sends (assuming it will check against trusted roots later)? I could
contend that a server implementation may not want to give such hints to a
client and assume that clients it trusts will present proper credentials
based on proper configuration.
Erik Tkal
