[Pki-devel] lightweight sub-CAs; updated design
Fraser Tweedale
ftweedal at redhat.com
Fri Oct 17 07:05:24 UTC 2014
On Thu, Oct 16, 2014 at 04:06:47PM +1000, Fraser Tweedale wrote:
> 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.
>
Further to previous email, I have been deep in the guts of the OCSP
implementation. I have updated the design proposal with my
findings.
http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs#OCSP_considerations
In brief, a single OCSP responder shared between all CAs seems like
it will be fine. Selection of an appropriate OCSP signing
certificate for signing the OCSP response still needs to be
designed, but shouldn't be difficult.
Next, I need to go back and have a close look at CRLs for sub-CAs.
OCSP is straightforward precisely because it pretty much just uses
the CRLs; the CRLs themselves might be less straightforward.
> > >>>>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
>
> _______________________________________________
> 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