[Freeipa-devel] DNSSEC design page

[Petr Spacek]

On 26.2.2014 15:20, Ludwig Krispenz wrote:
>>> 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.
Okay, then we can store all DNSSEC keys in one slot and use "key sets" only 
for administrative purposes (i.e. pairing zone <=> keys in BIND) but it will 
be invisible for PKCS#11 interface.

Key set maintenance has to go over side channel for metadata and not over PKCS#11.

> The pkcs11 data stored in ldap should represent pkcs11 objects. Other entries
> could reference these objects, eg a zone referencing a key. I don't think we
> should store references to other entries in an pkcs11 object. if you want this
> we probably need another auxiliary objectclass for these pkcs11 entries.
>
> Regarding objectclasses for the pkcs11 objects, what should be the structural
> objectclass and what the naming attribute ?
> So far I had defined the publicKey, privateKey, certificate objectclass all as
> auxiliary, maybe we should have one structural like pkcs11Object containing
> the required attrs like id, label, ...
> and a naming attr if it is not one of them
This sounds like a good idea.

-- 
Petr^2 Spacek