12:38 a.m.
On Wed, 2014-10-15 at 01:15 -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.
Actually, I'll respond here because the IPA thread has moved slightly
away from this. In the IPA thread, there is discussion of storing the
keys in ldap encrypted by some master key - which presumably would be
stored in the certdb.
Decrypting the signing key and keeping it in memory is absolutely a
no-no. The CA signing key material should only be present in the
HSM/softoken - and should never be exposed unencryted outside the token.
All crypto operations must be done there. That most likely means
storing the data in the NSS certdb.
Now, it might be possible to store the subca signing cert temporarily in
ldap (encrypted by a master key) when a subca is created. If the
replica detects that a new change has occurred in the DB (in the
relevant ou), it reads the data and stores the subca signing key.
Once all replica's have been updated, the entry is deleted.
New replica's need to get a pkcs12 file from an updated master in any
case.
> 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(a)redhat.com
> https://www.redhat.com/mailman/listinfo/pki-devel