Re: No CAs in CertificateRequest message

[Jeffrey Altman]

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   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Jeffrey Altman Subject: Re: No CAs in CertificateRequest message Richard Levitte - VMS Whacker wrote: In message <[EMAIL PROTECTED]> on Thu, 6 May 2004 08:24:57 -0400, "Erik Tkal" said: etssl> Can anyone answer this? How do I tell if this is a known etssl> problem with OpenSSL or if the RFC is incorrect, or if this is etssl> just a accepted deviation? I can't really say, as that's not my forte in OpenSSL, so what I say is just a guess. There are several places in OpenSSL (some ASN.1 stuff among others, IIRC) where the standards aren't entirely followed to the letter (you could say that the standards have been expanded a little bit, to be kind), so as not to break with some other software (I think Microsoft is often mentioned at this point...) that deviates from standards a little bit. My guess is that this possibility to generate an empty list of ceritificate requests may be that kind of deviation. I would love it if those in the team that really know the SSL parts  c ould give an accurate response...  I am certainly not an expert, but I thought the bending of the rules was on the side of accepting things that were not standard; not generating things which were not standard. At least anything that would result in generating non-standard output should have a SSL_OP flag associated with it. What code is being executed that is causing the zero length CA list?

smime.p7s
Description: S/MIME Cryptographic Signature