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

[Fraser Tweedale]

On Wed, Oct 15, 2014 at 03:58:51PM +0200, Petr Spacek wrote:
> On 15.10.2014 14:48, Simo Sorce wrote:
> >On Wed, 15 Oct 2014 17:48:35 +1000
> >Fraser Tweedale <ftweedal at redhat.com> wrote:
> >
> >>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.
> >
> >We use a softHSM for the DNSSEC stuff (in theory can be replaced by a
> >hw HSM too), and keys are handed within it only.
> 
> We are finishing DNSSEC right so I don't have time to study sub-CA design
> right now. For this reason I'm replying only with general statements:
> 
> - SoftHSM can be used as generic purpose token with PKCS#11 interface.
> - It supports multiple "PKCS#11 slots" in single SoftHSM installation so
> data can be separated as necessary: Each "slot" stores data in separate
> directory (with potentially different filesystem permissions, PINs etc.)
> - Upstream is responsive and accepts patches with new features (i.e.
> unimplemented pieces of PKCS#11 standard) without problems.
> - SoftHSM v2 code could use some cleanup but it has clear design and
> structure and I don't see extensibility problems.
> - Storage & crypto backends have clearly defined API so it should be
> possible to implement own back-ends (LDAP & NSS, if necessary).
> 
> Generally I don't see a reason why it couldn't not be used for as key
> storage mechanism for replicas (sub-CA keys, KDC master key, etc.) or even
> for clients (GNOME keyring backed with SSSD-SoftHSM tandem).
> 
> -- 
> Petr^2 Spacek

Thanks Simo and Petr for your input.

After some more investigation it looks like all the crypto in
Dogtag, including for KRA etc, is performed within the
``CryptoManager`` facility.  With that in mind, I've got a more
concrete implementation proposal that also uses ``CryptoManager``.
If it proves insufficient I will embark on a more detailed analysis
of feasibility/implications of bringing SoftHSM as a Dogtag
dependency (and remain open to other key distribution ideas).

One difference between the DNSSEC/SoftHSM design is that the master
key has to be unwrapped each time a sub-CA key needs to be
installed.  This was because I couldn't see a way to store and
retrieve a specific SymmetricKey in CryptoManager/CryptoToken.  If
there's a way to do this and I've just overlooked it, let me know.
But I don't think the security of the scheme is impacted ; it just
means that there's a bit of repeated work when we import sub-CA keys
from the database.

Direct link to key distribution implementation detail in the design proposal:
http://pki.fedoraproject.org/wiki/Lightweight_sub-CAs#CryptoManager_based_implementation

Cheers,

Fraser