[Freeipa-devel] DNSSEC design page

[Petr Spacek]

On 25.2.2014 15:32, Simo Sorce wrote:
> On Tue, 2014-02-25 at 14:52 +0100, Petr Spacek wrote:
>> On 25.2.2014 13:47, Jan Cholasta wrote:
>>> here is a draft of the PKCS#11 design:
>>> <http://www.freeipa.org/page/V3/PKCS11_in_LDAP>.
>>
>> I don't understand the purpose of cn=crypto suffix. I thought that PKCS#11
>> module will have to search for token with given TOKEN_ID or LABEL anyway,
>> right? Do I miss something?
>>
>> Where the token will be placed if someobody generates new key via PKCS#11? How
>> it will determine the right sub-tree?
>>
>> I would rather see keys stored under user account:
>> uid=admin,cn=users,cn=accounts,dc=ipa,dc=example
>
> User objects should stay as leaves imo.
> We can use the managed-by attribute to easily allow control by a user.

I have never understood to this design. Could you elaborate on that, please? 
I'm curious why it is designed in this way because from my point of view it 
adds complexity (managed by etc.) and I don't see the benefit.

>> I like this approach because it allows you to manipulate with the user account
>> easily without paying special attention to dangling references etc.
>
> the referential integrity plugin can handle references, usually.

... but the plugin can only delete references and nothing else, right? It 
works perfectly for user-group membership but it is not that great for keys. 
If you delete a user account then all associated keys will be there until 
somebody deletes them manually.

That is the reason why I don't like this design.

>> Key storage under service account like:
>> krbprincipalname=DNS/vm.example.com at IPA.EXAMPLE,cn=services,cn=accounts,dc=ipa,dc=example
>> doesn't solve problem with shared keys in DNS tree... I can imagine that
>> objects in LDAP have TOKEN_ID and LABEL attributes indexed and the PKCS#11
>> module will do full sub-tree search for particular ID or LABEL value, so the
>> key can be always found.
>
> DNS Keys should stay in the DNS tree IMHO.

That seems like an optimal solution, sure. I didn't realize that PKCS#11 
slot_id can be used to determine the right container for new keys.

>> On the other side, it would require special handling for replica deletion etc.
>
> Right.
>
> Simo.

-- 
Petr^2 Spacek