[Pki-devel] lightweight sub-CAs; updated design
Fraser Tweedale
ftweedal at redhat.com
Thu Oct 16 06:06:47 UTC 2014
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
> >>>>Pki-devel at redhat.com
> >>>>https://www.redhat.com/mailman/listinfo/pki-devel
> >>>
> >
> >_______________________________________________
> >Pki-devel mailing list
> >Pki-devel at redhat.com
> >https://www.redhat.com/mailman/listinfo/pki-devel
>
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel
More information about the Pki-devel
mailing list