[Freeipa-devel] DNSSEC design page

[Dmitri Pal]

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/