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

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
> 
> 