[Freeipa-devel] DNSSEC design page

[Simo Sorce]

On Tue, 2014-02-25 at 15:43 +0100, Petr Spacek wrote:
> 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.

One of the reasons is that normally you delete leaves with an ldap
delete operation, bit that will fail if the object is a node in a
subtree instead of a leaf.

You can delete entire subtrees but you need to explicitly make a
recursive delete and a lot of tools probably don't.

Adding leaves therefore has consequences that should not be
underestimated.

> >> 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.

We can solve this through the use of the managed entries plugin too I
think. We have ways to cope with this, I do not think we should waste
too much time on it though, for now.

> >> 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.

Ok.

Simo.


-- 
Simo Sorce * Red Hat, Inc * New York