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:

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:

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



Petr^2 Spacek

Freeipa-devel mailing list

Reply via email to