8:06 p.m.
One of the things that has been a long-standing obstacle to the automatic CA
code is the fact that there's no LDAP syntax/matchingrule/attributes for
storing private keys in the directory. There's schema for storing
userCertificate and cAcertificate, but not the corresponding keys. This is
also a stumbling block for being able to configure TLS directly in cn=config,
instead of using separate files.
Currently the autoca overlay defines a syntax and matching rule for use with
private keys but this needs to move into the core code so that back-config can
also use it. At this point I need to pick an OID arc for it, which prompted me
to troll thru all the existing OID assignments.
It's clear that nobody in the standards organizations considers storing
private keys in the directory to be a safe thing to do. IMO this is just a
matter of password security and good ACLs, and the standards should not
preclude the option. It is no worse than storing userPassword.
Comments?
openldap-commit2devel(a)OpenLDAP.org wrote:
A ref change was pushed to the OpenLDAP (openldap.git) repository.
It will be available in the public mirror shortly.
The branch, master has been updated
via 79284a06d3bea085ed92f17f2a2b5a15746f83a0 (commit)
via 2012795d3b1a29913e9f3a5b3a35d40fd8f5f903 (commit)
via b402a2805f8b96d2751a7315ea5e70e5082965ed (commit)
from 2b920ecaecc2e4858a33d0c8151bcf3b3d71cadd (commit)
Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.
- Log -----------------------------------------------------------------
commit 79284a06d3bea085ed92f17f2a2b5a15746f83a0
Author: Howard Chu <hyc(a)openldap.org>
Date: Sun Apr 9 03:55:01 2017 +0100
Catalog of assigned OID arcs
With some specific elements as well, but not exhaustively listed.
Patches welcome.
commit 2012795d3b1a29913e9f3a5b3a35d40fd8f5f903
Author: Howard Chu <hyc(a)openldap.org>
Date: Sun Apr 9 02:21:06 2017 +0100
Add config support for binary values
Use base64 for .conf files, straight binary for back-config
commit b402a2805f8b96d2751a7315ea5e70e5082965ed
Author: Howard Chu <hyc(a)openldap.org>
Date: Sun Apr 9 00:13:42 2017 +0100
Add options to use DER format cert+keys directly
Instead of loading from files.
-----------------------------------------------------------------------
Summary of changes:
doc/devel/OIDs | 69 ++++++++++++++++++++++++++++++++++++++++++
include/ldap.h | 3 ++
libraries/libldap/ldap-int.h | 6 ++++
libraries/libldap/tls2.c | 34 ++++++++++++++++++++-
libraries/libldap/tls_o.c | 56 +++++++++++++++++++++++++++++++---
servers/slapd/bconfig.c | 13 +++++++-
servers/slapd/config.c | 34 +++++++++++++++++++--
servers/slapd/config.h | 2 ++
8 files changed, 208 insertions(+), 9 deletions(-)
create mode 100644 doc/devel/OIDs
---
http://www.openldap.org/devel/gitweb.cgi?p=openldap.git
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
9:55 a.m.
Howard Chu wrote:
It's clear that nobody in the standards organizations considers
storing private keys in
the directory to be a safe thing to do. IMO this is just a matter of password security
and good ACLs, and the standards should not preclude the option. It is no worse than
storing userPassword.
Comparing CA keys with "storing userPassword" is too fuzzy:
1. Because I'm eagerly trying to avoid super-mighty (proxy) roles a single
compromised
password hopefully does not have such a broad security impact like a stolen CA private
key. And there's added 2FA to the mix for high security systems.
2. In my deployments I never store clear-text passwords in 'userPassword'. I
store
reversible encrypted shared secret with OATH-LDAP but they can only be decrypted by a
process outside slapd.
So if you plan to store private keys of CAs in DIT without extra encryption solely
relying on slapd's ACLs then IMO you have a pretty broad attack surface and I'd
never
recommend to anyone to use that.
Ciao, Michael.
2363
days inactive
2363
days old
1 comments
2 participants
participants (2)
-
Howard Chu -
Michael Ströder