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

On Fri, 2014-10-03 at 17:54 +1000, Fraser Tweedale wrote: I'll comment about that in the IPA thread. I had thought that the keys etc. would reside in the primary CA certdb. 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. 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. 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.