2:36 a.m.
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(a)redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel