On Tue, 2014-02-25 at 11:08 +0100, Petr Spacek wrote:
> On 24.2.2014 20:20, Simo Sorce wrote:

> > Also can you add some examples on how we would use these classes to
> > store DNS keys ?
> We need to think about it a bit more. We plan to use PKCS#11 for key 
> manipulation and data signing so the key itself will be unaware of any 
> DNSSEC-specific attributes. DNSSEC-specifics could be in an auxiliary 
> objectClass.
> I'm discussing this with CZ.NIC guys and they propose to add a 'layer of 
> indirection' between DNS zones and keys so one key set can be used by more 
> DNS 
> zones. They claim that it is relatively common practice and I trust them.
> Note that I'm not saying that IPA should use one key for multiple DNS zones 
> by 
> default, but the schema should be future-proof and allow that if necessary.

Makes sense.

> Let's start with this proposal:
> DNS zone: idnsname=dnssec.test, cn=dns, dc=example
> There will be multi-valued attribute idnsseckey pointing to DNs of keys 
> stored 
> somewhere else.
> Specifically for DNS, we could create sub-tree cn=dnsseckeys, cn=dns and 
> store 
> keys there.

Ok, do we really want to have zones pointing at keys ?
Or do we want keys have a list of zones they are supposed to apply to ?

> I expect that PKCS#11 module will handle keys scattered over the LDAP tree 
> somehow.

Sure as long as it can understand what the keys are for.

> > Ideally the example would show the LDAP tree and some example data in
> > detail, and also what operation we think would be common.

Simo Sorce * Red Hat, Inc * New York

Freeipa-devel mailing list

Reply via email to