[Freeipa-devel] DNSSEC design page

[Jan Cholasta]

On 25.2.2014 20:26, Petr Spacek wrote:
> 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

How will the PKCS#11 module know into which keyset to store a key 
generated by OpenDNSSEC? Are you suggesting having a separate slot/token 
for each keyset? I would like to keep the number of tokens low, because 
there are applications which go slot by slot, token by token when 
searching for objects (e.g. BIND and OpenSSH) and that might generate a 
lot of unnecessary traffic if the number of slots/tokens is high.

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

-- 
Jan Cholasta