[Freeipa-devel] DNSSEC design page

[Ludwig Krispenz]

On 02/27/2014 10:17 AM, Jan Cholasta wrote:
> 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.
do you mean to use this attributename or to use its values. I'd prefer 
to make the schema independent of other definitions if possible, so I 
thought of something like pkcs11objectId, which can have the same syntax 
as ipaUniqueid and use the same semantics.