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