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

[Ade Lee]

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.

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

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.
   

> 
> Look forward to your feedback,
> 
> Fraser
> 
> _______________________________________________
> Pki-devel mailing list
> Pki-devel at redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel