2:05 a.m.
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(a)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...
Cheers,
Fraser