Submission from: (NULL) (188.8.131.52)
Please update constant LDAP_CONTROL_DONTUSECOPY in ldap.h to OID 184.108.40.206.1.22 as
defined in RFC 6171 (Standards Track).
Currently an experimental OpenLDAP .666 OID is used which makes this control
rather unusable outside OpenLDAP implementation.
--On Monday, September 22, 2014 8:55 AM +0000 q03765(a)sohu.com wrote:
> Full_Name: Crane.YQ.Feng
> Version: 2.4.23
> OS: redhat linux 6.4
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (220.127.116.11)
> Hello openldap Expert,
> Could anyone do me a big favor. when i config my openldap's function
> about the password policy and to define the " olcPPolicyDefault ", a
> problem has occurted??
The ITS system is for reporting bugs, not asking usage questions. Use the
openldap-technical list for asking questions.
This ITS will be closed.
Zimbra :: the leader in open source messaging and collaboration
> Michael Ströder wrote:
>> On the downside it's a pain to deal with all the LDAP_OPT_X_TLS_* options
>> having no or different meaning/features for various crypto libs...
> Indeed. Even moreso if, as you seem to be suggesting, a client library gets
> built against a different TLS API than the server side. The current libldap
> infrastructure wouldn't even support such a build. (Although it could, as the
> original version of modular TLS support allowed all of the libraries to be
> supported concurrently. But we dropped that feature because there was no sane
> usecase for it.)
Personally I'd even prefer to have completely different LDAP_OPT_X_TLS_*
values and configuration directives for the different crypto APIs. In this
case one could really distinguish the different cases.
E.g. pointing to an OpenSSL CA certificate path is something completely
different than a libnss cert7.db/key3.db directory regarding the content even
though in both cases the option just is a directory path. IMHO this would
avoid a lot of the user/deployer confusion one can see on the mailing lists.
Well, for discussing this openldap-devel list would be the better forum.
> The real solution, if there are platform-specific keystores and such that you
> want to gain access to, is to submit patches for them to the OpenSSL project.
Hmm, openssl engine things are not really easy to deal with. I know that
PKCS#11 engine for OpenSSL exists. But such a stack has lots of loose ends.
Michael Ströder wrote:
> hyc(a)symas.com wrote:
>> gabriel(a)gritsch-soft.com wrote:
>>> would it be possible to support Apples "Common Crypto Services" instead of
>> But in general, it sounds like a bad idea. In light of Apple's now-infamous
>> "goto fail" bug
>> it would be poor practice to migrate away from a security package that is now
>> receiving broad and in-depth scrutiny, to one that only has Apple's assurances
>> behind it. Also given Apple's success rate with security in general
>> it seems like a poor choice.
> Yes, I agree with these concerns - especially for OpenLDAP server deployments.
> But there are some advantages using the OS platform's mainstream crypto lib
> for libldap to get access to the OS's own keyring (e.g. when using client certs).
> E.g. I'd avoid libnss for OpenLDAP servers but PKCS#11 in libnss gives some
> better access to smartcards.
OK, that may be nice to have. OpenSSL's engine API already allows such things
to be supported dynamically, though.
> On the downside it's a pain to deal with all the LDAP_OPT_X_TLS_* options
> having no or different meaning/features for various crypto libs...
Indeed. Even moreso if, as you seem to be suggesting, a client library gets
built against a different TLS API than the server side. The current libldap
infrastructure wouldn't even support such a build. (Although it could, as the
original version of modular TLS support allowed all of the libraries to be
supported concurrently. But we dropped that feature because there was no sane
usecase for it.)
The real solution, if there are platform-specific keystores and such that you
want to gain access to, is to submit patches for them to the OpenSSL project.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
This is a cryptographically signed message in MIME format.
Content-Type: text/plain; charset=ISO-8859-1
> gabriel(a)gritsch-soft.com wrote:
>> would it be possible to support Apples "Common Crypto Services" instea=
> But in general, it sounds like a bad idea. In light of Apple's now-infa=
> "goto fail" bug=20
> it would be poor practice to migrate away from a security package that =
> receiving broad and in-depth scrutiny, to one that only has Apple's ass=
> behind it. Also given Apple's success rate with security in general=20
> it seems like a poor choice.
Yes, I agree with these concerns - especially for OpenLDAP server deploym=
But there are some advantages using the OS platform's mainstream crypto l=
for libldap to get access to the OS's own keyring (e.g. when using client=
E.g. I'd avoid libnss for OpenLDAP servers but PKCS#11 in libnss gives so=
better access to smartcards.
On the downside it's a pain to deal with all the LDAP_OPT_X_TLS_* options=
having no or different meaning/features for various crypto libs...
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
Full_Name: Gabriel Gritsch
OS: Mac OS X 10.9.5
Submission from: (NULL) (18.104.22.168)
would it be possible to support Apples "Common Crypto Services" instead of
OpenSSL because the OpenSSL-functions are marked as deprecated since OS X 10.7
and produce a lot of warnings.