Turbo Fredriksson wrote:
On 9 Apr 2017, at 11:29, Howard Chu hyc@symas.com wrote:
Turbo Fredriksson wrote:
On 9 Apr 2017, at 04:06, Howard Chu hyc@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 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.
On 9 Apr 2017, at 14:40, Michael Ströder michael@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. ?
On 9 Apr 2017, at 14:24, Howard Chu hyc@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?
Turbo Fredriksson wrote:
On 9 Apr 2017, at 14:40, Michael Ströder michael@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.
-
Howard Chu -
Michael Ströder -
Turbo Fredriksson