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

Fraser Tweedale ftweedal at redhat.com
Wed Oct 15 07:48:35 UTC 2014


On Wed, Oct 15, 2014 at 01:38:09AM -0400, Ade Lee wrote:
> 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.
> 
The design of key distribution could follow the DNSSEC design; see
Petr Spacek's comments in this thread:
https://www.redhat.com/archives/freeipa-devel/2014-October/msg00080.html
Presumably this design for key distribution has received some
thorough attention.  Perhaps some of the assumption for DNSSEC do
not hold for Dogtag. I have copied Petr and Simo for their input.

Fraser

> 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 at redhat.com
> > > https://www.redhat.com/mailman/listinfo/pki-devel
> > 
> 
> 




More information about the Pki-devel mailing list