[Freeipa-devel] DNSSEC design page

[Jan Cholasta]

On 26.2.2014 17:37, Petr Spacek wrote:
> 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.

Yep.

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

+1, although what we refer to as "object" is referred to as "storage 
object" in the PKCS#11 spec, so we might name the object class 
ipaPkcs11storageObject.

As for the naming attribute, the only PKCS#11 attribute that can't ever 
be empty is CKA_CLASS, so I guess we'll have to use ipaUniqueId.

-- 
Jan Cholasta