[Pki-devel] lightweight sub-CAs; updated design
Fraser Tweedale
ftweedal at redhat.com
Wed Oct 15 07:36:33 UTC 2014
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.
> > 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?
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?
> 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
>
>
More information about the Pki-devel
mailing list