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

[Petr Spacek]

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