6:24 a.m.
Turbo Fredriksson wrote:
On 9 Apr 2017, at 11:29, Howard Chu <hyc(a)symas.com> wrote:
> Turbo Fredriksson wrote:
>> On 9 Apr 2017, at 04:06, Howard Chu <hyc(a)symas.com> wrote:
>>
>> Only difference might be that the local FS isn’t available _outside_ the host, a
directory
>> is.
>
> As soon as a host offers something like ssh, then that distinction is gone too.
True.
> Moreover, a secure mechanism for distributing private keys to users is required but
nobody
> ever specifies how to do that. Certainly LDAP/TLS is more manageable than sneakernet
and
> this is more bootstrappable.
Yeah, I’ve been struggling like crazy about this the last couple of months.
There’s many scripts and some products that can be/handle a CA, but
no one seems to have thought about the actual distribution of the result(s).
Or how to restrict queries, distribution and what type of cert is/can be requested.
And every link I’ve ever seen about certs, “then copy it securely to the
destination”. But no wording on HOW to do that or how to script it (in a
more .. “automated” fashion).
Everything I’ve seen about the subject is so darn _complex_! It shouldn’t HAVE
to be.
Indeed, there's no reason for it.
So if you can do something like this, and leave the ACL/policies etc
to the admin,
using existing functionality (ACL/ACI/ppolicy or whatever), I’d be a very happy man! :)
This is coming along now...
Are you actually talking about OpenLDAP being a “CA” as well? As in, being able
to create certificates by requests, or are you talking about OpenLDAP “only”
being the … “backend-storage” for such a tool?
The autoca overlay turns slapd into a CA. It can generate certificates for any
users (and servers) in the directory. Please read the slapo-autoca(5) manpage
for more info.
For bootstrapping purposes I'm now extending back-config to be able to use
certificates/keys stored directly in cn=config. The autoca overlay will be
extended to store its generated CA cert in cn=config, so that a slapd can
immediately support TLS as soon as the overlay is used (without requiring
restarts).
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
6:40 a.m.
New subject: Storing TLS credentials in the directory
Howard Chu wrote:
Turbo Fredriksson wrote:
> Everything I’ve seen about the subject is so darn _complex_! It shouldn’t HAVE
> to be.
Indeed, there's no reason for it.
Hmm, every time in a customer encryption/PKI project the customer requested that it
should be secure *and* easy to use. This is kind of a contradiction to begin with.
Also this short discussion already oversimplifys all the possible use-cases and
considerations when talking about storing/using/protecting private keys. Personally
I'd
never use such a autoca overlay running on the "normal" directory server.
So every technical design should start with a decent description of the use-cases or will
blatantly fail. This will lead to reviewing which name spaces have to be put in which
naming extension for which usage and who is authorized to use the keys and issue certs.
Simply starting with schema for private key storage is putting the cart before the horse.
Having said this I'm willing to contribute to such a design.
I have some ideas which are very much based on the role model in Æ-DIR though.
(Well, I sweared to myself not to develop another PKI system again. But every other
implementation pretty much sucks, especially in the naming, registration, authorization
parts...umpf! But be assured: It's *very* hard to get it really right.)
Ciao, Michael.
8:46 a.m.
New subject: Storing TLS credentials in the directory
On 9 Apr 2017, at 14:40, Michael Ströder <michael(a)stroeder.com> wrote:
Hmm, every time in a customer encryption/PKI project the customer
requested that it
should be secure *and* easy to use. This is kind of a contradiction to begin with.
(Well, I sweared to myself not to develop another PKI system again. But every other
implementation pretty much sucks, especially in the naming, registration, authorization
parts...umpf! But be assured: It's *very* hard to get it really right.)
I think, without having actually done it myself, nor have I used something like this
in production, is that “The CA Solution (tm)” tries to do _EVERYTHING_ (!!) that
could possibly be done in/with a CA.
But if you boil it down to the minimum requirements, all it should be able/have to
do is:
1) Receive a [hostname/fqdn/full name] request for a [host/user] certificate
2) Create the public/private key for that request
3) Sign it with the CA cert “in storage” (root or intermediate)
4) Hand that over to the requester in as secure way as possible
At least, that is all _I_ want/need. I’m sure there’s hundreds of other things to be
done,
but if we keep it simple, this is all it should have to do.
I’m going to have to read up on slapo-autoca, because I’ve never heard about that
before.
But when I started my thread about “CA product” a few weeks ago, I think I got an
answer saying it was not maintained any more… ?
But considering Howards discussion on private keys, I’m assuming that it doesn’t
have the core basic above. ?
9:47 a.m.
New subject: Storing TLS credentials in the directory
Turbo Fredriksson wrote:
On 9 Apr 2017, at 14:40, Michael Ströder <michael(a)stroeder.com>
wrote:
> Hmm, every time in a customer encryption/PKI project the customer requested that it
> should be secure *and* easy to use. This is kind of a contradiction to begin with.
>
> (Well, I sweared to myself not to develop another PKI system again. But every other
> implementation pretty much sucks, especially in the naming, registration,
> authorization parts...umpf! But be assured: It's *very* hard to get it really
> right.)
I think, without having actually done it myself, nor have I used something like this
in production, is that “The CA Solution (tm)” tries to do _EVERYTHING_ (!!) that
could possibly be done in/with a CA.
Well, issuing server certs is just one use-case.
People bothering to implement a full PKI project usually want to do more.
But if you boil it down to the minimum requirements, all it should be
able/have to
do is:
1) Receive a [hostname/fqdn/full name] request for a [host/user] certificate
2) Create the public/private key for that request
3) Sign it with the CA cert “in storage” (root or intermediate)
4) Hand that over to the requester in as secure way as possible
Well, that's the use-case to issue server certs. IMO in this case the key pair and
thus
the private key do not have be available at the CA at all. The CA should only
authenticate and sign CSRs which should be done on a separate system.
Server certs for most protocols are used as TLS server certs only authenticating DNS
names (plural!). Today putting a TLS server's FQDN in the CN attribute of the subject
DN
is deprecated. IMHO you cannot even rely on every TLS implementation looking at subject
DN anymore. This also means that you have to associate a set of FQDNs with the server
entity, not just a subject DN with CN.
The tricky point is how to securely authorize a responsible admin to get a server cert
issued by the CA on behalf of that server.
In Æ-DIR I have aeHost and aeService objects representing hosts and server services. I
can add FQDNs to these objects with a unique constraint effectively lock usage of the
FQDN.
Furthermore for each of those objects I can determine the responsible roles "setup
admin"
or "zone admin" (already extensively used in (set-based) ACLs). So for each FQDN
to be
added to a server cert I can reliably find a set of authorized user accounts to act on
behalf of that server.
Therefore the idea is for the RA is to implement a LDAP-based CSR queue with
(set-/value-based) OpenLDAP ACLs/constraints to only allow the responsible admin roles to
place a CSR referencing the Æ entity itself and associated FQDNs. The CA will just pull
CSRs from this queue and sign the pre-validated CSRs.
So far the rough Æ-DIR idea for this particular use-cases.
More use-cases to consider:
1. client certs for personal user accounts (aeUser) for TLS client certs, SSH authz keys
2. client certs for system user accounts (aeService) for TLS client certs, SSH authz keys
3. e-mail certs (reversible encryption)
4. certs to be used for securely storing shared secrets
etc.
I'm eager to do 1. integrated with this process used in OATH-LDAP:
https://oath-ldap.stroeder.com/docs.html#img_oath-ldap-enroll
Ciao, Michael.
P.S.: We should discuss this in more detail at LDAPcon 2017.
9:29 a.m.
New subject: Storing TLS credentials in the directory
On 9 Apr 2017, at 14:24, Howard Chu <hyc(a)symas.com> wrote:
Please read the slapo-autoca(5) manpage for more info.
This is exactly how easy I’m envisioning this to be! Brilliant, thanx!
So if I’m understanding this correctly, all you have to do to request
a certificate for a specific object, is to read the “userPrivateKey;binary”
of that RDN?
Now, I know it’s well to early for feature requests :D, but I have a few
questions (and a feature request :):
1) Why is both certificates (private AND public) in the same attribute?
I can see the reason to have the public … “public” (with a much
more relaxed ACL/ACI).
2) What if I want a new certificate for that RDN?
Such as the previous one is [about to] expire and it needs to be
refreshed (preferably (?) without destroying/removing the old one).
3) Is the CAs _public_ key available as well?
Same reason as point 1.
4) If I already have a CA “on premises” and that have created an
intermediate CA I’d like to use for “autoca”, could this be done?
2247
days inactive
2247
days old
4 comments
3 participants
participants (3)
-
Howard Chu -
Michael Ströder -
Turbo Fredriksson