On 02/25/2014 08:46 AM, Simo Sorce wrote:
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 ?
If we plan to store DNS keys in one place and other keys in other places
in the tree (no common key store) then it really does not matter much.
It should be derived from the LDAP searches that would need to be
conducted by the software.
We need keys for signing, right?
Any other use case?
If for signing we will start with a zone and would need to find keys
that are relevant to this zone.
It seems that having a generic key class + auxiliary class that would
keep metadata about the key, its expiration and DN it applies to would
be a way to go.
So it seems that I agree with Simo that it would make sense to have the
zone the key applies to specified in the key entry rather than in the
zone entry.
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.
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
