[Freeipa-devel] Multiple CA certificates in LDAP, questions

[Simo Sorce]

On Tue, 2013-09-10 at 10:30 +0200, Jan Cholasta wrote:
> On 9.9.2013 17:54, Simo Sorce wrote:
> > On Mon, 2013-09-09 at 10:40 -0400, Rob Crittenden wrote:
> >> Jan Cholasta wrote:
> >>> On 9.9.2013 16:02, John Dennis wrote:
> >>>> On 09/09/2013 05:17 AM, Jan Cholasta wrote:
> >>>>> Another question:
> >>>>>
> >>>>> Should each IPA service (LDAP, HTTP, PKINIT) have its own distinctive
> >>>>> set of trusted CAs, or is using one set for everything good enough?
> >>>>> Using distinctive sets would allow granular control over what CA is
> >>>>> trusted for what service (e.g. trust CA1 to issue certificates for LDAP
> >>>>> and HTTP, but trust CA2 only to issue certificates for HTTP), but I'm
> >>>>> not sure how useful that would be in the real world.
> >>>>
> >>>> That would complicate things quickly. Managing CA certs is already
> >>>> challenging enough. Exploding this via combinations does not seem to
> >>>> present enough real value for the complexity.
> >>>>
> >>>> In the real world most deployments boil down to a single CA and that
> >>>> trust model been effective. Don't forget you can always revoke any cert
> >>>> issued by a CA. Having granular control over individual CA's does not
> >>>> seem to present value, just complications. If your CA is compromised
> >>>> you've got big things to worry about, having it be 1 in N does not seem
> >>>> to change that equation radically. If one CA got compromised you've got
> >>>> a lot of work to do to replace the trusted CA list everywhere. If one is
> >>>> compromised why aren't the other CA's? Having to update just one CA
> >>>> trust rather than potentially N is better.
> >>>
> >>> I'm not suggesting *controlling* multiple CAs, but being able to manage
> >>> what individual external CAs are trusted to do. This is probably only
> >>> relevant to CA-less install. When IPA internal CA is installed, there is
> >>> just that one CA, which is trusted for everything.
> >>>
> >>
> >> We've fielded questions from people wanting to replace the cert in the
> >> web server even while maintaining the IPA CA. Granted this was prior to
> >> the CA-less option.
> >
> >> The impetus seems to be not requiring all users to trust the IPA CA. I
> >> think if that became easier then wanting to use another CA would be less
> >> of an issue.
> >
> > And I really think this would be better served with an SNI setup, where
> > we have 2 SSL certs for the web server only (a public one and an IPA
> > one). While everything else must use the IPA CA, esp for PKINIT.
> 
> What if there is no IPA CA (CA-less)? Should we assume that the user has 
> their own CA in control and allow only certs signed by that single CA?
> 
> Regarding SNI, it apparently is not supported in server-side NSS 
> (https://bugzilla.mozilla.org/show_bug.cgi?id=360421) 

We need to either push for a solution to this or allow to switch to
mod_ssl.

> and Python 2.x 
> (http://bugs.python.org/issue5639).

This issue seem for python 3.2, do we actually use python code to
perform SSL connections to HTTP servers ? I am not sure we do.

>  These seem like blockers to me, 
> correct me if I'm wrong.

Yes they are blockers, so we need to either solve them ourselves or work
around.

Simo.

-- 
Simo Sorce * Red Hat, Inc * New York