[Freeipa-devel] DNSSEC design page

[Jan Cholasta]

On 27.2.2014 11:28, Ludwig Krispenz wrote:
>
> 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.
>

I meant ipaUniqueId the attribute, but I'm fine with anything else 
(pkcs11UniqueId perhaps? to avoid confusion with pkcs11Id)

-- 
Jan Cholasta