On 25.2.2014 20:26, Petr Spacek wrote:
On 25.2.2014 19:13, Dmitri Pal wrote:
On 02/25/2014 08:46 AM, Simo Sorce wrote:
On Tue, 2014-02-25 at 11:08 +0100, Petr Spacek wrote:
On 24.2.2014 20:20, Simo Sorce wrote:
Also can you add some examples on how we would use these classes to
store DNS keys ?
We need to think about it a bit more. We plan to use PKCS#11 for key
manipulation and data signing so the key itself will be unaware of any
DNSSEC-specific attributes. DNSSEC-specifics could be in an auxiliary
objectClass.
I'm discussing this with CZ.NIC guys and they propose to add a
'layer of
indirection' between DNS zones and keys so one key set can be used
by more DNS
zones. They claim that it is relatively common practice and I trust
them.
Note that I'm not saying that IPA should use one key for multiple
DNS zones by
default, but the schema should be future-proof and allow that if
necessary.
Makes sense.
Let's start with this proposal:
DNS zone: idnsname=dnssec.test, cn=dns, dc=example
There will be multi-valued attribute idnsseckey pointing to DNs of
keys stored
somewhere else.
Specifically for DNS, we could create sub-tree cn=dnsseckeys, cn=dns
and store
keys there.
Ok, do we really want to have zones pointing at keys ?
Or do we want keys have a list of zones they are supposed to apply to ?
If we plan to store DNS keys in one place and other keys in other
places in
the tree (no common key store) then it really does not matter much.
It should be derived from the LDAP searches that would need to be
conducted by
the software.
We need keys for signing, right?
Any other use case?
In DNSSEC-context no, but the same principle will be re-used for CA
certificates and possibly user-keys (in future, like SSH private keys or
certificated used from Firefox).
If for signing we will start with a zone and would need to find keys
that are
relevant to this zone.
It seems that having a generic key class + auxiliary class that would
keep
metadata about the key, its expiration and DN it applies to would be a
way to go.
Yes, this is the plan.
So it seems that I agree with Simo that it would make sense to have
the zone
the key applies to specified in the key entry rather than in the zone
entry.
Practically it doesn't matter. You have to do either search to find
zones associated with given key or another search to find keys
associated with given zone.
Maybe the version with list of zones stored in key is better from ACI's
point of view. Access to list of zones will be controlled with ACI
attached to the key object.
... Would it be a problem to have bi-directional link between key and
zone (member-memberOf style)? It would ease processing on the client
side and I think that the price is not that high. We can use existing
member and memberOf attributes if we decide to do that.
I expect that PKCS#11 module will handle keys scattered over the
LDAP tree
somehow.
Sure as long as it can understand what the keys are for.
Ideally the example would show the LDAP tree and some example data in
detail, and also what operation we think would be common.
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.
See the attached picture.
Are you okay with that? If so, we need to somehow add key rotation
policy to this mix :-)
This machinery has to allow algorithm-rollover, keysize-rollover etc.
We can get some inspiration from
https://wiki.opendnssec.org/display/DOCS/kasp.xml . Note that OpenDNSSEC
1.x can't do algorithm-rollover so we need to be creative with the design.
--
Jan Cholasta
_______________________________________________
Freeipa-devel mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/freeipa-devel
