Turbo Fredriksson wrote: > On 9 Apr 2017, at 14:40, Michael Ströder <mich...@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.
smime.p7s
Description: S/MIME Cryptographic Signature
