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 Freeipa-devel@redhat.com https://www.redhat.com/mailman/listinfo/freeipa-devel