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
> 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
> 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
> default, but the schema should be future-proof and allow that if necessary.
> 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
> somewhere else.
> Specifically for DNS, we could create sub-tree cn=dnsseckeys, cn=dns and
> 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
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