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 _______________________________________________ Freeipa-devel mailing list [email protected] https://www.redhat.com/mailman/listinfo/freeipa-devel
