Cryptography Reference
In-Depth Information
the server to indicate what sorts of certifi cates it would accept, and by which CAs.
This makes some sense. The most likely use case for a client-side authentication
is a private CA, not one of the public, shared, pre-trusted (and expensive!) ones.
As long as the CA's private key is kept private, it's no less secure than a public
CA. In fact, it might be more secure.
The format of the CertificateRequest message is fi rst a list of the types of
certifi cates it accepts; TLS 1.0 defi nes four: rsa_sign , dss_sign , rsa_fixed_dh ,
and dss_fixed_dh . Following this is a list of the ASN.1 DER-encoded distin-
guished names of the certifi cate authorities that the server trusts. The specifi ca-
tion is silent on whether this list must contain any entries or is allowed to be
empty, and what to do if the list of trusted CAs is empty. Some implementations
respond with an empty list to indicate that any CA is trusted. Although this
sort of defeats the purpose, you should be aware that it is a possible condition.
Adding Certifi cate Request Parsing Capability for the Client
The client has no way of knowing when a server might demand a client cer-
tifi cate, so it has to be ready to handle the request, whether by supplying a
certifi cate or by aborting the connection. Add a new fl ag to TLSParameters as
shown in Listing 8-27.
Listing 8-27: “tls.h” TLSParameters with certifi cate request fl ag
typedef struct
{
int peer_finished;
int got_certificate_request;
digest_ctx md5_handshake_digest;
}
TLSParameters;
Of course, as with all potential handshake messages, you need to add a new
conditional in receive_tls_msg as shown in Listing 8-28.
Listing 8-28: “tls.c” receive_tls_msg with certifi cate request support
static int receive_tls_msg( int connection,
char *buffer,
int bufsz,
TLSParameters *parameters )
{
case certificate_request: // Abort if server requests a certificate?
read_pos = parse_certificate_request( read_pos, parameters );
break;
Search WWH ::




Custom Search