[Pki-devel] lightweight sub-CAs; updated design
Christina Fu
cfu at redhat.com
Thu Oct 16 00:37:17 UTC 2014
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.
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 ;-).
>>>> 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.
>>
>> 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
More information about the Pki-devel
mailing list