Ben Laurie <[EMAIL PROTECTED]>:
> Bodo Moeller:
>> It appears to me that while it is reasonable to employ the same
>> cert_st structure for SSL_CTX's and SSL's (if the inconsistencies in
>> the current code are removed, as I suggested in the first paragraph),
>> the re-use of cert_st for sessions makes not a lot of sense
>> altogether; that is, not only is the current implementation broken,
>> but a corrected one should use a specific data structure that
>> is appropriate for its needs instead of kludging around with cert_st.
> I certainly agree that they current situation is a mess - adding session
> IDs was very confusing because of all this. I'm not sure exactly what
> you think cert_st shouldn't be used for - storing cert chains?
I think there should be one structure (whatever its name will be) that
is used to store all that stuff that can have defaults set in SSL_CTX
(and can be overridden in SSL's derived from that SSL_CTX). So
certificate chains of the other end of a connection definitely
wouldn't go into this structure, and neither would individual
certificates or public keys of peers.
When redesigning that, the behaviour of the library likely will
change, but only in rather harmless ways. For example, I think the
structure should be copied by SSL_new, which means that any changes
done to a SSL_CTX after the SSL_new won't be visible to the SSL
structure; and it means that setting a key for a SSL does not
de-activate temporary keys that were previously set in the SSL_CTX
(which now can happen, as the SSL's cert_st does not copy any defaults
from the SSL_CTX's cert_st -- sometimes the values from the SLS_CTX's
crt_st are accessed, sometimes only those of the SSL's cert_st).
> Anyway, I agree that it needs sorting out. Not sure exactly how, though.
Yeah, who does ...
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
