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
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
- zone objects: idnsname=example.net,cn=dns and
- 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
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
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
The pkcs11 data stored in ldap should represent pkcs11 objects. Other
could reference these objects, eg a zone referencing a key. I don't
should store references to other entries in an pkcs11 object. if you
we probably need another auxiliary objectclass for these pkcs11 entries.
Regarding objectclasses for the pkcs11 objects, what should be the
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
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
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.
Freeipa-devel mailing list