On 24.2.2014 20:20, Simo Sorce wrote:
On Mon, 2014-02-24 at 13:11 +0100, Ludwig Krispenz wrote:

here is a draft to start discussion. Lt me know if it is the right
direction and what you're missing.

I think we need to think hard if you really can make all those
attributes a MUST for the private key, as not all the attributes seem to
apply to all encryption algorithms. Would have to have to add bogus
attributes in some cases.

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.

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.

I expect that PKCS#11 module will handle keys scattered over the LDAP tree somehow.

Ideally the example would show the LDAP tree and some example data in
detail, and also what operation we think would be common.

Petr^2 Spacek

Freeipa-devel mailing list

Reply via email to