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

On Wed, Oct 15, 2014 at 05:37:17PM -0700, Christina Fu wrote: > First, I have a question regarding the design History for "rejected design: > sub-CA subsystem (Solution) 1". > I'm not sure I understand the stated disadvantage regarding having to keep > separate admin certs and need to find out which cert to authenticate. Isn't > that the same thing with the other co-existing subsystems such as KRA as > well? How is the sub-CA making it any more different? maybe I missed > something, but I actually am not convinced that this is enough reason to > make drastic changes in the code that could weaken the stability of the > product. > You are right - on it's own, it is not enough reason. But the main reason for rejection (I will update the earlier list to include it) is stated in the ``Reasons for rejection'' section: The challenge of spawning sub-CA subsystems on multiple clones is likely to introduce a lot of complexity and may be brittle. The alternative solution of storing sub-CA configuration in the database, thus allowing easy replication, was preferred. > Now for the design... > please see my comments in-line below. > > Christina > > On 10/15/2014 07:37 AM, Ade Lee wrote: > >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. > > For CRL's, Each CA needs to sign its own CRL or delegate to its CRL issuer. > a CRL issuer is a cert that contains the crlSign key extension which is > signed by the CA itself, the same CA that issues the certs. > The OCSP responses have to be signed by the the OCSP signer that has the > ocspSigning extended key usage extension which is signed by the CA itself, > the same CA that issues the certs asking for validation. > when handling multiple crls from different ca's, iff you have one single > ocsp instance, each time a request comes in, you will need to make sure you > sign the responses with the right corresponding ocsp signing cert or the > validation will fail. > > I filed a ticket recently: https://fedorahosted.org/pki/ticket/1179 > I'll be happy if you take care of that while you are at it ;-). > I need to understand OCSP properly, but according to your preceding comments it does seem that each sub-CAs will have a corresponding OCSP signing cert. So the ticket certainly appears to be in scope for this feature.

> >>>>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. > > Yes that was my thought as well.. having separate SigningUnit's. > I'm not sure you want separate CA's to share the same config and profiles as > that seems to defeat the purpose of calling it out as a separate CA. > yes, I just saw Ade's suggestion about defining shared and non-shared. I > agree that you should think it through. > I disagree that it defeats the purpose - the driving use case is easily created (at any time) security subdomains within a Dogtag instance. I think we will always want sub-CAs to support multiple profiles (even though this may be a limited number). This means that there must be a way to specify a profile. So my thoughts are to support all profiles for now, at least for the first cut of this feature. The changes to restrict which profiles a sub-CA can use can come later as the use cases are clarified. I will add a section to the design proposal for exploring issues related to profiles. Fraser > > >> > >>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 > &gt;&gt;&gt;&gt;Pki-devel(a)redhat.com > >>>>https://www.redhat.com/mailman/listinfo/pki-devel > >>> > > > >_______________________________________________ > >Pki-devel mailing list > &gt;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 _______________________________________________ Pki-devel mailing list Pki-devel(a)redhat.com https://www.redhat.com/mailman/listinfo/pki-devel