Re: [Pki-devel] lightweight sub-CAs; updated design

On Wed, 2014-10-15 at 17:36 +1000, Fraser Tweedale wrote: > On Wed, Oct 15, 2014 at 01:15:28AM -0400, Ade Lee wrote: >> On Fri, 2014-10-03 at 17:54 +1000, Fraser Tweedale wrote: >>> Hi all, >>> >>> Just landed a big update to the lightweight sub-CAs design proposal: >>> http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs. >>> >>> I plan to start the implementing next week. Aside from general >>> design review, specific things I need input on are: >>> >>> 1) >>> >>> How to propagate newly-generated sub-CA private keys to clones in >>> an automated way, and how to store them. >>> >> I'll comment about that in the IPA thread. I had thought that the >> keys etc. would reside in the primary CA certdb. >> >>> 2) >>> >>> REST API; whether to have a separate resource for sub-CAs, e.g. >>> ``/ca/ee/ca/subca1/...``, or whether to use explicit parameters to >>> indicate a sub-CAs. >>> >> Endi just added a ticket that I think is really overdue. >> https://fedorahosted.org/pki/ticket/1183 >> >> This more closely treats the different subsystems as different webapps >> within a single tomcat instance. It will make it possible to >> deploy/undeploy subsystems simply by removing the context.xml file. >> >> Does it make sense to treat the subCA's as separate webapps, and >> therefore deploy or undeploy them simply by creating or removing a >> context.xml file? This would imply /ca/ee/ca/subca1/... etc. >> > The current design has them as part of the same web app, with > path or query parameters to distinguish between CAs. > > To my intuition, this should be a simpler and - with the current > deployment situation - less disruptive option than separate webapps. > A downside to this approach is somewhat more complicated routing, > more parameters to process and mechanism needed to select the > correct SigningUnit. There may be critical downsides that were > overlooked - let me know. OK - lets go with that approach for now and see where we end up. >>> 2a) >>> >>> Similarly, for OCSP - whether to use a single OCSP responder for all >>> the CAs in an instance or whether to have separate responders for >>> different [sub-]CAs.

>>> 3) >>> >>> The other main change in the design (I'm open to reconsidering but >>> the more I thought about it, the more it made sense) is that there >>> will be one CertificateAuthority object for the sub-CA (as well as >>> the primary CA), and likewise one CertificateRepository object for >>> each CA. The certificate repositories will be hierarchical OUs in >>> LDAP so that it will be straightforward to search all certificates, >>> or just those that were issued by a particular [sub-]CA. Details >>> are in the document. >>> >> Each CertificateAuthority object owns a number of associated objects >> that are constructed when the CertificateAuthority object is constructed >> - a sample of them is below. Do you plan to have a separate CS.cfg >> config files? separate log files? separate serial number generators? >> >> protected ISubsystem mOwner = null; >> protected IConfigStore mConfig = null; >> protected ILogger mLogger = CMS.getLogger(); >> protected Hashtable<String, ICRLIssuingPoint> mCRLIssuePoints = new Hashtable<String, ICRLIssuingPoint>(); >> protected CRLIssuingPoint mMasterCRLIssuePoint = null; // the complete crl. >> protected SigningUnit mSigningUnit; >> protected SigningUnit mOCSPSigningUnit; >> protected SigningUnit mCRLSigningUnit; >> protected CertificateRepository mCertRepot = null; >> protected CRLRepository mCRLRepot = null; >> protected ReplicaIDRepository mReplicaRepot = null; >> >> protected CertificateChain mCACertChain = null; >> protected CertificateChain mOCSPCertChain = null; >> >> protected PublisherProcessor mPublisherProcessor = null; >> protected IRequestQueue mRequestQueue = null; >> protected CAPolicy mPolicy = null; >> protected CAService mService = null; >> protected IRequestNotifier mNotify = null; >> protected IRequestNotifier mPNotify = null; >> >> public IRequestListener mCertIssuedListener = null; >> public IRequestListener mCertRevokedListener = null; >> public IRequestListener mReqInQListener = null; >> >> protected Hashtable<String, ListenerPlugin> mListenerPlugins = null; >> >> Once you instantiate all of this, you start to wonder just how >> "lightweight" this solution is. Yes, the separation is potentially >> cleaner - but its not really any better than deploying a bunch of full >> blown CA webapps within the same tomcat instance. >> >> I'm imagining a situation where - in openstack, different projects might >> want to issue certs from their own subCA's. This is potentially a large >> number of subCAs. >> > Indeed. I think should be able to share request queues and > listeners easily enough. The CA SigningUnit will probably need to > be separate for each subCA. Shared-vs-independent CRL and OCSP > SigningUnits need more investigation.

> > CertificateChain objects will probably be different for each sub-CAs > despite sub-CAs obviously sharing most of the chain with siblings. > Too bad they didn't use a plain old cons list :) > > Voicing of concerns about lightweight sub-CAs not being so > lightweight are appreciated. Are there any specific concers about > performance, or just general wariness? > I have a general wariness about sharing resources like listeners, publishers etc. between multiple CA objects when they were probably not designed to be used in that manner. That could lead to hard to diagnose synchronization issues. If we plan to share almost all the resources - including config files, log files, most system certs -- and treat the subcas as part of the primary CA webapp, then the subCA's really are a different animal than the primary CA - and should be represented accordingly. It may make sense to create a CA instance as : CA { Shared_Stuff HashTable (Non_Shared_Stuff for subCA's) NonSharedObject getNonSharedObject(sub_ca_id) { if (sub_ca_id == Null) return NonSharedObject(default) else return NonSharedObject(sub_ca_id) } } I think it makes sense to identify the things that need to be different for subCA's and focus on making sure the correct objects are loaded there. Separating into completely separate CA instances might ultimately be cleaner, but it wouldn't be my first cut. > The use case is really API-driven sub-CA creation (and use) in an > existing instance, so maybe the feature needs a re-brand? > "Low-overhead sub-CAs" or "Shared-instance sub-CAs" or something? > The name is fine, as most resources are shared. Its the synchronization of objects that worries me. >> Is the reason for multiple CertificateRepository directories so that you >> could separate certs (and presumably requests too) into different repos? >> Can/should the subCAs have different serial number generators (and >> therefore most likely collisions)? >> Ultimately, I think the simpler approach will be to use a single >> CertificateRepository - albeit with changes to account for sub-ou's for >> each subca. >> > Ok, so we agree on hierarchical OUs for the cert repo schema. I > will examine the needed changes to CertificateRepository to support > this, and we can compare. It might just be some new optional > parameters for specifying a subCA. > > (The reason for multiple CertificateRepository objects was that it > would mean few changes - just instantiate for each OU. So, not an > important reason.) > > Cheers, > > Fraser > >>> Look forward to your feedback, >>> >>> Fraser >>> >>> _______________________________________________ >>> Pki-devel mailing list >>> Pki-devel(a)redhat.com >>> https://www.redhat.com/mailman/listinfo/pki-devel >> _______________________________________________ Pki-devel mailing list Pki-devel(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-devel