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