[Freeipa-devel] DNSSEC design page

[Petr Spacek]

On 25.2.2014 19:13, Dmitri Pal wrote:
> 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?
In DNSSEC-context no, but the same principle will be re-used for CA 
certificates and possibly user-keys (in future, like SSH private keys or 
certificated used from Firefox).

> 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.
Yes, this is the plan.

> 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.
Practically it doesn't matter. You have to do either search to find zones 
associated with given key or another search to find keys associated with given 
zone.

Maybe the version with list of zones stored in key is better from ACI's point 
of view. Access to list of zones will be controlled with ACI attached to the 
key object.

... Would it be a problem to have bi-directional link between key and zone 
(member-memberOf style)? It would ease processing on the client side and I 
think that the price is not that high. We can use existing member and memberOf 
attributes if we decide to do that.

>>> 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.

I was talking about 'layer of indirection' previously. I'm digging into 
details and it seems like a good idea to imitate what DNS registrars do - use 
concept of key sets. It means that keys are not linked to a zone one by one 
but rather a whole set of keys is linked to a zone.

It eases key rotation because you just need to drop a new key to a key set and 
you don't have to add DNs of all zones to the new key (or the other way around).

Another thing is that you could have different key rotation policies for 
different key sets... we need to think about it carefully.

For example (without policies for now):
- two DNS zones example.com and example.net contain a pointer to keyset called 
'setA'
- zone objects: idnsname=example.net,cn=dns and idnsname=example.com,cn=dns

- key sets are stored under cn=keysets, cn=sec, cn=dns

- individual keys are stored under keyid=key1, keysetid=setA, cn=keysets, 
cn=sec, cn=dns

See the attached picture.

Are you okay with that? If so, we need to somehow add key rotation policy to 
this mix :-)

This machinery has to allow algorithm-rollover, keysize-rollover etc.  We can 
get some inspiration from https://wiki.opendnssec.org/display/DOCS/kasp.xml . 
Note that OpenDNSSEC 1.x can't do algorithm-rollover so we need to be creative 
with the design.

-- 
Petr^2 Spacek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: keyset-tree.png
Type: image/png
Size: 49208 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/freeipa-devel/attachments/20140225/091a165c/attachment.png>