RE: No CAs in CertificateRequest message

[Erik Tkal]

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?