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 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. > Key storage under service account like: > krbprincipalname=DNS/vm.example.com@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. > On the other side, it would require special handling for replica deletion etc. Right. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ Freeipa-devel mailing list Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel