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.
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
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
