Re: [Freeipa-devel] [PATCH] 0052..0054 Configure lightweight CA key replication

2016-06-09 Thread Jan Cholasta 

On 9.6.2016 08:31, Fraser Tweedale wrote:

On Thu, Jun 09, 2016 at 07:49:51AM +0200, Jan Cholasta wrote:

On 9.6.2016 06:07, Fraser Tweedale wrote:

Updated patches 0053-6 and 0054-6 attached.  Comments inline.

Thanks,
Fraser

On Wed, Jun 08, 2016 at 10:31:07AM +0200, Jan Cholasta wrote:

Patch 0052:

The target of the "Dogtag service principals can search Custodia keys" ACI
matches keys in the top-level Custodia container, but not in the Dogtag
container. Is this intentional?


ACI applies to all entries under the 'cn=custodia' tree, not only
the entries directly under it.


You are right:



Mea culpa, I thought the target matching behavior was simpler than this.

Anyway, could the ACI be tightened to allow access only to the Dogtag
subtree?


Dogtag does need access to the host Custodia keys.


I see, the ACI is OK then.


I'm not sure how
to tighten the ACI to prevent access to "deeper" levels.  In any
case they're all public keys and it's read only access, so I don't
think it's an issue.


Right.







Patch 0053:

It seems the `servicename`+`host` and `principal` arguments of set_key() are
carrying the same information, could you remove one of them?


OK, just `principal` now.



Patch 0054:

1) Please use ipalib.config to read IPA configuration in
ipa-pki-retrieve-key:

from ipalib.config import Env

env = Env(in_server=True)
hostname = env.host
realm = env.realm


I have implemented this; it was necessary to also call
`env._finalize()`.


Right. I wrote the above snippet off the top of my head, hence the omission.




2) I'm curious why you changed the key name from "ca/$NAME" to
"ca_wrapped/$NAME". Aren't *all* keys in Custodia wrapped?


The payload of the `ca_wrapped` Custodia store is a
PKIArchiveOptions object wrapped by the main CA's private key.
(This payload is then encrypted by Custodia, as all Custodia
payloads are).

See my patch 0056 [1] for implementation details.

[1] https://www.redhat.com/archives/freeipa-devel/2016-May/msg00079.html


Wow, I totally missed patch 0055 and 0056!


No worries; easily done because I sent more emails with fewer,
largely independent patches.




3) Given that Dogtag ExternalProcessKeyRetriever handles JSON *now*, I would
expect a minimum required version bump in the spec file.


Indeed; I added this in latest patches.


Thanks. ACK if the ACI in patch 52 does not need tightening.


Thanks for reviewing!


Pushed to master: b0d9a4728f0dc78e2bbde344beac17ae50b847a9

--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH] 0052..0054 Configure lightweight CA key replication

2016-06-09 Thread Fraser Tweedale 
On Thu, Jun 09, 2016 at 07:49:51AM +0200, Jan Cholasta wrote:
> On 9.6.2016 06:07, Fraser Tweedale wrote:
> > Updated patches 0053-6 and 0054-6 attached.  Comments inline.
> > 
> > Thanks,
> > Fraser
> > 
> > On Wed, Jun 08, 2016 at 10:31:07AM +0200, Jan Cholasta wrote:
> > > Patch 0052:
> > > 
> > > The target of the "Dogtag service principals can search Custodia keys" ACI
> > > matches keys in the top-level Custodia container, but not in the Dogtag
> > > container. Is this intentional?
> > > 
> > ACI applies to all entries under the 'cn=custodia' tree, not only
> > the entries directly under it.
> 
> You are right:
> 
> 
> 
> Mea culpa, I thought the target matching behavior was simpler than this.
> 
> Anyway, could the ACI be tightened to allow access only to the Dogtag
> subtree?
> 
Dogtag does need access to the host Custodia keys.  I'm not sure how
to tighten the ACI to prevent access to "deeper" levels.  In any
case they're all public keys and it's read only access, so I don't
think it's an issue.

> > 
> > > 
> > > Patch 0053:
> > > 
> > > It seems the `servicename`+`host` and `principal` arguments of set_key() 
> > > are
> > > carrying the same information, could you remove one of them?
> > > 
> > OK, just `principal` now.
> > 
> > > 
> > > Patch 0054:
> > > 
> > > 1) Please use ipalib.config to read IPA configuration in
> > > ipa-pki-retrieve-key:
> > > 
> > > from ipalib.config import Env
> > > 
> > > env = Env(in_server=True)
> > > hostname = env.host
> > > realm = env.realm
> > > 
> > I have implemented this; it was necessary to also call
> > `env._finalize()`.
> 
> Right. I wrote the above snippet off the top of my head, hence the omission.
> 
> > 
> > > 2) I'm curious why you changed the key name from "ca/$NAME" to
> > > "ca_wrapped/$NAME". Aren't *all* keys in Custodia wrapped?
> > > 
> > The payload of the `ca_wrapped` Custodia store is a
> > PKIArchiveOptions object wrapped by the main CA's private key.
> > (This payload is then encrypted by Custodia, as all Custodia
> > payloads are).
> > 
> > See my patch 0056 [1] for implementation details.
> > 
> > [1] https://www.redhat.com/archives/freeipa-devel/2016-May/msg00079.html
> 
> Wow, I totally missed patch 0055 and 0056!
> 
No worries; easily done because I sent more emails with fewer,
largely independent patches.

> > 
> > > 3) Given that Dogtag ExternalProcessKeyRetriever handles JSON *now*, I 
> > > would
> > > expect a minimum required version bump in the spec file.
> > > 
> > Indeed; I added this in latest patches.
> 
> Thanks. ACK if the ACI in patch 52 does not need tightening.
> 
Thanks for reviewing!

-- 
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH] 0052..0054 Configure lightweight CA key replication

2016-06-08 Thread Jan Cholasta 

On 9.6.2016 06:07, Fraser Tweedale wrote:

Updated patches 0053-6 and 0054-6 attached.  Comments inline.

Thanks,
Fraser

On Wed, Jun 08, 2016 at 10:31:07AM +0200, Jan Cholasta wrote:

Patch 0052:

The target of the "Dogtag service principals can search Custodia keys" ACI
matches keys in the top-level Custodia container, but not in the Dogtag
container. Is this intentional?


ACI applies to all entries under the 'cn=custodia' tree, not only
the entries directly under it.


You are right:



Mea culpa, I thought the target matching behavior was simpler than this.

Anyway, could the ACI be tightened to allow access only to the Dogtag 
subtree?






Patch 0053:

It seems the `servicename`+`host` and `principal` arguments of set_key() are
carrying the same information, could you remove one of them?


OK, just `principal` now.



Patch 0054:

1) Please use ipalib.config to read IPA configuration in
ipa-pki-retrieve-key:

from ipalib.config import Env

env = Env(in_server=True)
hostname = env.host
realm = env.realm


I have implemented this; it was necessary to also call
`env._finalize()`.


Right. I wrote the above snippet off the top of my head, hence the omission.




2) I'm curious why you changed the key name from "ca/$NAME" to
"ca_wrapped/$NAME". Aren't *all* keys in Custodia wrapped?


The payload of the `ca_wrapped` Custodia store is a
PKIArchiveOptions object wrapped by the main CA's private key.
(This payload is then encrypted by Custodia, as all Custodia
payloads are).

See my patch 0056 [1] for implementation details.

[1] https://www.redhat.com/archives/freeipa-devel/2016-May/msg00079.html


Wow, I totally missed patch 0055 and 0056!




3) Given that Dogtag ExternalProcessKeyRetriever handles JSON *now*, I would
expect a minimum required version bump in the spec file.


Indeed; I added this in latest patches.


Thanks. ACK if the ACI in patch 52 does not need tightening.

--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH] 0052..0054 Configure lightweight CA key replication

2016-06-08 Thread Fraser Tweedale 
Updated patches 0053-6 and 0054-6 attached.  Comments inline.

Thanks,
Fraser

On Wed, Jun 08, 2016 at 10:31:07AM +0200, Jan Cholasta wrote:
> Patch 0052:
> 
> The target of the "Dogtag service principals can search Custodia keys" ACI
> matches keys in the top-level Custodia container, but not in the Dogtag
> container. Is this intentional?
> 
ACI applies to all entries under the 'cn=custodia' tree, not only
the entries directly under it.

> 
> Patch 0053:
> 
> It seems the `servicename`+`host` and `principal` arguments of set_key() are
> carrying the same information, could you remove one of them?
> 
OK, just `principal` now.

> 
> Patch 0054:
> 
> 1) Please use ipalib.config to read IPA configuration in
> ipa-pki-retrieve-key:
> 
> from ipalib.config import Env
> 
> env = Env(in_server=True)
> hostname = env.host
> realm = env.realm
> 
I have implemented this; it was necessary to also call
`env._finalize()`.

> 2) I'm curious why you changed the key name from "ca/$NAME" to
> "ca_wrapped/$NAME". Aren't *all* keys in Custodia wrapped?
> 
The payload of the `ca_wrapped` Custodia store is a
PKIArchiveOptions object wrapped by the main CA's private key.
(This payload is then encrypted by Custodia, as all Custodia
payloads are).

See my patch 0056 [1] for implementation details.

[1] https://www.redhat.com/archives/freeipa-devel/2016-May/msg00079.html

> 3) Given that Dogtag ExternalProcessKeyRetriever handles JSON *now*, I would
> expect a minimum required version bump in the spec file.
> 
Indeed; I added this in latest patches.
From 5116bc9cd4a2f3f1dde4fbc5f941b091036fa78c Mon Sep 17 00:00:00 2001
From: Fraser Tweedale 
Date: Mon, 11 Apr 2016 12:42:35 +1000
Subject: [PATCH 53/54] Optionally add service name to Custodia key DNs

Lightweight CAs support introduces new service principals for
Dogtag, with Custodia keys.  The current Custodia key creation uses
a DN that contains only they key type and the hostname, so keys for
multiple services on the same host cannot be created.

Add the 'generate_keys' method to generate keys for a host or an
arbitrary service.  When a service name is given, add the key
entries in a nested container with RDN 'cn='.  (The
container is assumed to exist).

This change does not affect searching because subtree search is
used, filtering on the ipaKeyUsage and memberPrincipal attributes.

Part of: https://fedorahosted.org/freeipa/ticket/4559
---
 ipapython/secrets/kem.py | 27 ++-
 1 file changed, 22 insertions(+), 5 deletions(-)

diff --git a/ipapython/secrets/kem.py b/ipapython/secrets/kem.py
index 
0abf28ae4403a7b6225404df361d12cb07ccc70b..d45efe8cc4fb63ae9d8c0b2c920fd1f9e5331a9d
 100644
--- a/ipapython/secrets/kem.py
+++ b/ipapython/secrets/kem.py
@@ -3,6 +3,7 @@
 from __future__ import print_function
 from ipaplatform.paths import paths
 from six.moves.configparser import ConfigParser
+from ipapython.dn import DN
 from cryptography.hazmat.backends import default_backend
 from cryptography.hazmat.primitives import serialization
 from cryptography.hazmat.primitives.asymmetric import rsa, ec
@@ -105,11 +106,24 @@ class KEMLdap(iSecLdap):
 encoding=serialization.Encoding.DER,
 format=serialization.PublicFormat.SubjectPublicKeyInfo)
 
-def set_key(self, usage, host, principal, key):
+def set_key(self, usage, principal, key):
+"""
+Write key for the host or service.
+
+Service keys are nested one level beneath the 'cn=custodia'
+container, in the 'cn=' container; this allows
+fine-grained control over key management permissions for
+specific services.
+
+The container is assumed to exist.
+
+"""
 public_key = self._format_public_key(key)
 conn = self.connect()
+servicename, host = principal.split('@')[0].split('/')
 name = '%s/%s' % (KEY_USAGE_MAP[usage], host)
-dn = 'cn=%s,%s' % (name, self.keysbase)
+service_rdn = ('cn', servicename) if servicename != 'host' else DN()
+dn = str(DN(('cn', name), service_rdn, self.keysbase))
 try:
 mods = [('objectClass', ['nsContainer',
  'ipaKeyPolicy',
@@ -170,15 +184,18 @@ class IPAKEMKeys(KEMKeysStore):
 return conn.get_key(usage, kid)
 
 def generate_server_keys(self):
-principal = 'host/%s@%s' % (self.host, self.realm)
+self.generate_keys('host')
+
+def generate_keys(self, servicename):
+principal = '%s/%s@%s' % (servicename, self.host, self.realm)
 # Neutralize the key with read if any
 self._server_keys = None
 # Generate private key and store it
 pubkeys = newServerKeys(self.config['server_keys'], principal)
 # Store public key in LDAP
 ldapconn = KEMLdap(self.ldap_uri)
-ldapconn.set_key(KEY_USAGE_SIG, self.host, principal, pubkeys[0])
-ldapconn.set_key(KEY_USAGE_ENC,

Re: [Freeipa-devel] [PATCH] 0052..0054 Configure lightweight CA key replication

2016-06-08 Thread Jan Cholasta 

On 6.6.2016 15:32, Fraser Tweedale wrote:

On Wed, Jun 01, 2016 at 02:49:29PM +1000, Fraser Tweedale wrote:

Updated patches attached; comments inline.

On Thu, May 05, 2016 at 04:52:29PM +1000, Fraser Tweedale wrote:

I would rather add a new ACI than have one super-ACI for everything. That
way you don't have to invent any complicated naming schemes *and* it will be
more apparent what the ACI does.


OK, I'll simplify the scheme and create corresponding ACIs.


I added new ACIs for hosts to manage Dogtag keys; they keys live in
a container with RDN cn=dogtag, nested under the main custodia keys
container.


However, calling `CAInstance.setup_lightweight_ca_key_retrieval()'
*directly* from `ca.install_step_1' would probably work.  Are you
happy with putting it there, instead of `configure_instance()'?


Works for me.


Cool, thanks.


This is implemented in the latest patch.


Rebased and updated patches attached.  The only substantive change
is a simplification of the ipa-pki-retrieve-key script (patch 0054)
following a change in Dogtag's ExternalProcessKeyRetriever (it now
handles JSON).


Patch 0052:

The target of the "Dogtag service principals can search Custodia keys" 
ACI matches keys in the top-level Custodia container, but not in the 
Dogtag container. Is this intentional?



Patch 0053:

It seems the `servicename`+`host` and `principal` arguments of set_key() 
are carrying the same information, could you remove one of them?



Patch 0054:

1) Please use ipalib.config to read IPA configuration in 
ipa-pki-retrieve-key:


from ipalib.config import Env

env = Env(in_server=True)
hostname = env.host
realm = env.realm

2) I'm curious why you changed the key name from "ca/$NAME" to 
"ca_wrapped/$NAME". Aren't *all* keys in Custodia wrapped?


3) Given that Dogtag ExternalProcessKeyRetriever handles JSON *now*, I 
would expect a minimum required version bump in the spec file.


--
Jan Cholasta

--
Manage your subscription for the Freeipa-devel mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-devel
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Re: [Freeipa-devel] [PATCH] 0052..0054 Configure lightweight CA key replication

2016-06-06 Thread Fraser Tweedale 
On Wed, Jun 01, 2016 at 02:49:29PM +1000, Fraser Tweedale wrote:
> Updated patches attached; comments inline.
> 
> On Thu, May 05, 2016 at 04:52:29PM +1000, Fraser Tweedale wrote:
> > > I would rather add a new ACI than have one super-ACI for everything. That
> > > way you don't have to invent any complicated naming schemes *and* it will 
> > > be
> > > more apparent what the ACI does.
> > > 
> > OK, I'll simplify the scheme and create corresponding ACIs.
> > 
> I added new ACIs for hosts to manage Dogtag keys; they keys live in
> a container with RDN cn=dogtag, nested under the main custodia keys
> container.
> 
> > > >>However, calling `CAInstance.setup_lightweight_ca_key_retrieval()'
> > > >>*directly* from `ca.install_step_1' would probably work.  Are you
> > > >>happy with putting it there, instead of `configure_instance()'?
> > > 
> > > Works for me.
> > > 
> > Cool, thanks.
> > 
> This is implemented in the latest patch.
>
Rebased and updated patches attached.  The only substantive change
is a simplification of the ipa-pki-retrieve-key script (patch 0054)
following a change in Dogtag's ExternalProcessKeyRetriever (it now
handles JSON).

Thanks,
Fraser
From 1a88facefdbfd1bccc3177a8777f417cdaa4ced7 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale 
Date: Tue, 3 May 2016 13:22:39 +1000
Subject: [PATCH] Add ACIs for Dogtag custodia client

The "dogtag/$HOSTNAME@$REALM" service principal uses Custodia to
retrieve lightweight CA signing keys, and therefore needs search and
read access to Custodia keys.  Add an ACI to permit this.

Also add ACIs to allow host principals to manage Dogtag custodia
keys for the same host.

Part of: https://fedorahosted.org/freeipa/ticket/4559
---
 install/updates/20-aci.update | 8 
 1 file changed, 8 insertions(+)

diff --git a/install/updates/20-aci.update b/install/updates/20-aci.update
index 
4802ae0458e8b870bf3127764ebabac1a48f7cf2..0d617d849be8a1fdc76bdeeda7560b032a45e629
 100644
--- a/install/updates/20-aci.update
+++ b/install/updates/20-aci.update
@@ -136,3 +136,11 @@ add:aci: (target = 
"ldap:///cn=replication,cn=etc,$SUFFIX;)(targetattr = "nsDS5R
 dn: cn=ipa,cn=etc,$SUFFIX
 add:aci: (target = 
"ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX")(version 3.0; acl "IPA 
server hosts can create own Custodia secrets"; allow(add) groupdn = 
"ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX; and userdn = 
"ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";)
 add:aci: (target = 
"ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX")(targetattr = 
"ipaPublicKey")(version 3.0; acl "IPA server hosts can manage own Custodia 
secrets"; allow(write) groupdn = 
"ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX; and userdn = 
"ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";)
+
+# IPA server hosts can create and manage Dogtag Custodia secrets for same host
+dn: cn=ipa,cn=etc,$SUFFIX
+add:aci: (target = 
"ldap:///cn=*/($$dn),cn=dogtag,cn=custodia,cn=ipa,cn=etc,$SUFFIX")(version 3.0; 
acl "IPA server hosts can create Dogtag Custodia secrets for same host"; 
allow(add) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX; 
and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";)
+add:aci: (target = 
"ldap:///cn=*/($$dn),cn=dogtag,cn=custodia,cn=ipa,cn=etc,$SUFFIX")(targetattr = 
"ipaPublicKey")(version 3.0; acl "IPA server hosts can manage Dogtag Custodia 
secrets for same host"; allow(write) groupdn = 
"ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX; and userdn = 
"ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";)
+
+# Dogtag service principals can search Custodia keys
+add:aci: (target = 
"ldap:///cn=*,cn=custodia,cn=ipa,cn=etc,$SUFFIX;)(targetattr = "ipaPublicKey || 
ipaKeyUsage || memberPrincipal")(version 3.0; acl "Dogtag service principals 
can search Custodia keys"; allow(read, search, compare) userdn = 
"ldap:///krbprincipalname=dogtag/*@$REALM,cn=services,cn=accounts,$SUFFIX;;)
-- 
2.5.5

From b8df17c8a42a144907c76d949ec25d5a61526ed4 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale 
Date: Mon, 11 Apr 2016 12:42:35 +1000
Subject: [PATCH 53/54] Optionally add service name to Custodia key DNs

Lightweight CAs support introduces new service principals for
Dogtag, with Custodia keys.  The current Custodia key creation uses
a DN that contains only they key type and the hostname, so keys for
multiple services on the same host cannot be created.

Add the 'generate_keys' method to generate keys for a host or an
arbitrary service.  When a service name is given, add the key
entries in a nested container with RDN 'cn='.  (The
container is assumed to exist).

This change does not affect searching because subtree search is
used, filtering on the ipaKeyUsage and memberPrincipal attributes.

Part of: https://fedorahosted.org/freeipa/ticket/4559
---
 ipapython/secrets/kem.py | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git

Re: [Freeipa-devel] [PATCH] 0052..0054 Configure lightweight CA key replication

2016-05-31 Thread Fraser Tweedale 
Updated patches attached; comments inline.

On Thu, May 05, 2016 at 04:52:29PM +1000, Fraser Tweedale wrote:
> > I would rather add a new ACI than have one super-ACI for everything. That
> > way you don't have to invent any complicated naming schemes *and* it will be
> > more apparent what the ACI does.
> > 
> OK, I'll simplify the scheme and create corresponding ACIs.
> 
I added new ACIs for hosts to manage Dogtag keys; they keys live in
a container with RDN cn=dogtag, nested under the main custodia keys
container.

> > >>However, calling `CAInstance.setup_lightweight_ca_key_retrieval()'
> > >>*directly* from `ca.install_step_1' would probably work.  Are you
> > >>happy with putting it there, instead of `configure_instance()'?
> > 
> > Works for me.
> > 
> Cool, thanks.
> 
This is implemented in the latest patch.

Cheers,
Fraser
From 7395f98bcec1e54b076cf9e2ceac1e4368cfe7c9 Mon Sep 17 00:00:00 2001
From: Fraser Tweedale 
Date: Tue, 3 May 2016 13:22:39 +1000
Subject: [PATCH] Add ACIs for Dogtag custodia client

The "dogtag/$HOSTNAME@$REALM" service principal uses Custodia to
retrieve lightweight CA signing keys, and therefore needs search and
read access to Custodia keys.  Add an ACI to permit this.

Also add ACIs to allow host principals to manage Dogtag custodia
keys for the same host.

Part of: https://fedorahosted.org/freeipa/ticket/4559
---
 install/updates/20-aci.update | 8 
 1 file changed, 8 insertions(+)

diff --git a/install/updates/20-aci.update b/install/updates/20-aci.update
index 
4802ae0458e8b870bf3127764ebabac1a48f7cf2..0d617d849be8a1fdc76bdeeda7560b032a45e629
 100644
--- a/install/updates/20-aci.update
+++ b/install/updates/20-aci.update
@@ -136,3 +136,11 @@ add:aci: (target = 
"ldap:///cn=replication,cn=etc,$SUFFIX;)(targetattr = "nsDS5R
 dn: cn=ipa,cn=etc,$SUFFIX
 add:aci: (target = 
"ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX")(version 3.0; acl "IPA 
server hosts can create own Custodia secrets"; allow(add) groupdn = 
"ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX; and userdn = 
"ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";)
 add:aci: (target = 
"ldap:///cn=*/($$dn),cn=custodia,cn=ipa,cn=etc,$SUFFIX")(targetattr = 
"ipaPublicKey")(version 3.0; acl "IPA server hosts can manage own Custodia 
secrets"; allow(write) groupdn = 
"ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX; and userdn = 
"ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";)
+
+# IPA server hosts can create and manage Dogtag Custodia secrets for same host
+dn: cn=ipa,cn=etc,$SUFFIX
+add:aci: (target = 
"ldap:///cn=*/($$dn),cn=dogtag,cn=custodia,cn=ipa,cn=etc,$SUFFIX")(version 3.0; 
acl "IPA server hosts can create Dogtag Custodia secrets for same host"; 
allow(add) groupdn = "ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX; 
and userdn = "ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";)
+add:aci: (target = 
"ldap:///cn=*/($$dn),cn=dogtag,cn=custodia,cn=ipa,cn=etc,$SUFFIX")(targetattr = 
"ipaPublicKey")(version 3.0; acl "IPA server hosts can manage Dogtag Custodia 
secrets for same host"; allow(write) groupdn = 
"ldap:///cn=ipaservers,cn=hostgroups,cn=accounts,$SUFFIX; and userdn = 
"ldap:///fqdn=($$dn),cn=computers,cn=accounts,$SUFFIX";)
+
+# Dogtag service principals can search Custodia keys
+add:aci: (target = 
"ldap:///cn=*,cn=custodia,cn=ipa,cn=etc,$SUFFIX;)(targetattr = "ipaPublicKey || 
ipaKeyUsage || memberPrincipal")(version 3.0; acl "Dogtag service principals 
can search Custodia keys"; allow(read, search, compare) userdn = 
"ldap:///krbprincipalname=dogtag/*@$REALM,cn=services,cn=accounts,$SUFFIX;;)
-- 
2.5.5

From 78bdf20af5dfaaa67ba0ba8b160f18c8cf31d54c Mon Sep 17 00:00:00 2001
From: Fraser Tweedale 
Date: Mon, 11 Apr 2016 12:42:35 +1000
Subject: [PATCH 53/54] Optionally add service name to Custodia key DNs

Lightweight CAs support introduces new service principals for
Dogtag, with Custodia keys.  The current Custodia key creation uses
a DN that contains only they key type and the hostname, so keys for
multiple services on the same host cannot be created.

Add the 'generate_keys' method to generate keys for a host or an
arbitrary service.  When a service name is given, add the key
entries in a nested container with RDN 'cn='.  (The
container is assumed to exist).

This change does not affect searching because subtree search is
used, filtering on the ipaKeyUsage and memberPrincipal attributes.

Part of: https://fedorahosted.org/freeipa/ticket/4559
---
 ipapython/secrets/kem.py | 26 +-
 1 file changed, 21 insertions(+), 5 deletions(-)

diff --git a/ipapython/secrets/kem.py b/ipapython/secrets/kem.py
index 
0abf28ae4403a7b6225404df361d12cb07ccc70b..0b810b090a0e7dff09d64a5ef8752eba2676babc
 100644
--- a/ipapython/secrets/kem.py
+++ b/ipapython/secrets/kem.py
@@ -3,6 +3,7 @@
 from __future__ import print_function
 from ipaplatform.paths import paths
 from six.moves.configparser import