>It was easy to abstract apr_ldap_init() to support STARTTLS, it's not as >easy to abstract it to support client certificates.
After thinking about it a little more, is teaching apr_ldap_init() to support STARTTLS the right thing to do in apr-util? My understanding is that the purpose of start_tls is to be able to on the fly, convert back and forth between an unsecure connection and a secure connection when required. By teaching apr_ldap_init() to support start_tls, once you have created a secure connection on 389, it's permanent. You don't have the option, at least through apr-util, to initially create an unsecure connection and then at some later point, convert the connection to a secure connection. Or converting back to unsecure from secure. Should starting and stopping TLS be a separate API in apr-util rather than part of apr_ldap_init()? Brad >>> "Graham Leggett" <[EMAIL PROTECTED]> Thursday, January 06, 2005 1:11 AM >>> Brad Nicholes said: > The problem is that other SDKs such as Novell, do not use > ldap_set_option() to set the certificates or the SSL mode. Novell uses > ldapssl_add_trusted_cert() and ldapssl_start_tls(). As it stands the > apr_ldap_add_cert() function allows you to add as many certificates as > you like doing the correct thing for all SDKs under the covers. > apr_ldap_init() is doing the right thing as far as starting SSL, TLS or > clear ldap connection regardless of the SDK. Using > apr_ldap_set_option() to set certificates or SSL modes would be SDK > specific. It has to be abstracted by APR. That was exactly the point - it would be abstracted by APR. I think the concern seems to be that the API is getting messy, which is exactly the thing we're trying to move away from. It was easy to abstract apr_ldap_init() to support STARTTLS, it's not as easy to abstract it to support client certificates. How are client certificates specified within the Novell toolkit? Regards, Graham --
