Re: [Freeipa-devel] [DESIGN] Sub-CAs; authenticating to Custodia
On Tue, 2016-04-19 at 21:57 -0400, Simo Sorce wrote: > On Wed, 2016-04-20 at 11:32 +1000, Fraser Tweedale wrote: > > On Tue, Apr 19, 2016 at 07:48:27AM +0200, Jan Cholasta wrote: > > > On 14.4.2016 08:56, Jan Cholasta wrote: > > > >On 7.4.2016 16:17, Petr Spacek wrote: > > > >>On 7.4.2016 15:20, Fraser Tweedale wrote: > > > >>>On Thu, Apr 07, 2016 at 12:29:00PM +0200, Jan Cholasta wrote: > > > On 7.4.2016 12:13, Christian Heimes wrote: > > > >On 2016-04-07 11:09, Petr Spacek wrote: > > > >>On 7.4.2016 08:43, Fraser Tweedale wrote: > > > >>>Hi team, > > > >>> > > > >>>I updated the Sub-CAs design page with more detail for the key > > > >>>replication[1]. This part of the design is nearly complete (a > > > >>>large > > > >>>patchset is in review over at pki-devel@) but there are various > > > >>>options about how to authenticate to Custodia. > > > >>> > > > >>>[1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication > > > >>> > > > >>>In brief, the options are: > > > >>> > > > >>>1) authenticate as host principal; install binary setuid > > > >>>root:pkiuser to read host keytab and custodia keys. > > > >> > > > >>Huh, I really do not like this. Host keytab on IPA master is one > > > >>of the most > > > >>sensitive keys we have. > > > >> > > > >>Maybe gssproxy can be used somehow, but I think it would be better > > > >>to use > > > >>separate key. > > > >> > > > >> > > > >>>2) authenticate as host principal; copy host keytab and custodia > > > >>>keys to location readable by pkiuser. > > > >> > > > >>No, really, do not copy host keytab anywhere. > > > >> > > > >> > > > >>>3) create new principal for pkiuser to use, along with custodia > > > >>>keys > > > >>>and keytab in location readable by pkiuser. > > > >>> > > > >>>I prefer option (1) for reasons outlined in the design page. The > > > >>>design page goes into quite a bit more detail so please review the > > > >>>section linked above and get back to me with your thoughts. > > > >> > > > >>The only downside of (3) using new keys is: > > > >>... This approach requires the creation of new principals, and > > > >>Kerberos > > > >>keytabs and Custodia keys for those principals, as part of the > > > >>installation/upgrade process. > > > >> > > > >>Compared with additional SUID binary this seems as safer and > > > >>easier way to go. > > > >>FreeIPA installers already create quite a lot of principals and > > > >>keytabs so > > > >>this is well understood task. > > > >> > > > >>I would do (3). > > > > > > > >+1 for (3) > > > > > > > >A SUID binary feels like a dangerous hack. > > > > > > +1 > > > > > > >>>OK, (3) it is. Thanks all for your input. > > > >>> > > > >>>Now for next question: what should service principal name be? I > > > >>>think `dogtag/example@example.com' but am open to other > > > >>>suggestions, e.g. `pki/...'. > > > >> > > > >>Do you plan to attempt to standardize this name in future? I do not > > > >>expect that. > > > >> > > > >>Considering private nature of it, it should be as specific as possible > > > >>to > > > >>avoid any potential conflicts with future standards. > > > >>"dogtag-key-replication" > > > >>sounds like a good candidate. > > > > > > > >IMO it shouldn't be *that* specific, considering we want to switch > > > >Dogtag from SSL to GSSAPI authentication to DS, which will probably use > > > >the same principal name. I think "ipa-pki/..." or "dogtag/..." should be > > > >fine. > > > > > > (Forgot to CC Fraser.) > > > > > What is HTTP client support like for principal names with service > > part /= "HTTP"? > > As a target ? > None, in which case are you going to use the dogtag keytab for the > acceptor though ? > > > For communication from IPA framework to Dogtag, > > we will need a way to force the client to use an alternative service > > name. > > Our pbox design says differently. > We'll just interpose gssproxy and we'll be able to safely share the HTTP > key for all services. Ah this is not finalized yet, but attached find an initial draft. > > As for the actual service name, I will use "dogtag/..." > > Good to use as a client. > > Simo. > > > Cheers, > > Fraser > > > > > > > > > >> > > > >>Before you set the name in stone make sure it does not conflict with > > > >>anything > > > >>listed on > > > >>http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml > > > >> > > > >> > > > >>These names have potential to be used by someone else. > > > > > > > > > > -- > > > Jan Cholasta > > > > -- Simo Sorce * Red Hat, Inc * New York P-Box-option-1.pdf Description: Adobe PDF document -- Manage your subscription for the Freeipa-devel mailing list: https://www.redhat.com/mailman/listinfo/freeipa-devel Contribute to
Re: [Freeipa-devel] [DESIGN] Sub-CAs; authenticating to Custodia
On Wed, 2016-04-20 at 11:32 +1000, Fraser Tweedale wrote: > On Tue, Apr 19, 2016 at 07:48:27AM +0200, Jan Cholasta wrote: > > On 14.4.2016 08:56, Jan Cholasta wrote: > > >On 7.4.2016 16:17, Petr Spacek wrote: > > >>On 7.4.2016 15:20, Fraser Tweedale wrote: > > >>>On Thu, Apr 07, 2016 at 12:29:00PM +0200, Jan Cholasta wrote: > > On 7.4.2016 12:13, Christian Heimes wrote: > > >On 2016-04-07 11:09, Petr Spacek wrote: > > >>On 7.4.2016 08:43, Fraser Tweedale wrote: > > >>>Hi team, > > >>> > > >>>I updated the Sub-CAs design page with more detail for the key > > >>>replication[1]. This part of the design is nearly complete (a large > > >>>patchset is in review over at pki-devel@) but there are various > > >>>options about how to authenticate to Custodia. > > >>> > > >>>[1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication > > >>> > > >>>In brief, the options are: > > >>> > > >>>1) authenticate as host principal; install binary setuid > > >>>root:pkiuser to read host keytab and custodia keys. > > >> > > >>Huh, I really do not like this. Host keytab on IPA master is one > > >>of the most > > >>sensitive keys we have. > > >> > > >>Maybe gssproxy can be used somehow, but I think it would be better > > >>to use > > >>separate key. > > >> > > >> > > >>>2) authenticate as host principal; copy host keytab and custodia > > >>>keys to location readable by pkiuser. > > >> > > >>No, really, do not copy host keytab anywhere. > > >> > > >> > > >>>3) create new principal for pkiuser to use, along with custodia keys > > >>>and keytab in location readable by pkiuser. > > >>> > > >>>I prefer option (1) for reasons outlined in the design page. The > > >>>design page goes into quite a bit more detail so please review the > > >>>section linked above and get back to me with your thoughts. > > >> > > >>The only downside of (3) using new keys is: > > >>... This approach requires the creation of new principals, and > > >>Kerberos > > >>keytabs and Custodia keys for those principals, as part of the > > >>installation/upgrade process. > > >> > > >>Compared with additional SUID binary this seems as safer and > > >>easier way to go. > > >>FreeIPA installers already create quite a lot of principals and > > >>keytabs so > > >>this is well understood task. > > >> > > >>I would do (3). > > > > > >+1 for (3) > > > > > >A SUID binary feels like a dangerous hack. > > > > +1 > > > > >>>OK, (3) it is. Thanks all for your input. > > >>> > > >>>Now for next question: what should service principal name be? I > > >>>think `dogtag/example@example.com' but am open to other > > >>>suggestions, e.g. `pki/...'. > > >> > > >>Do you plan to attempt to standardize this name in future? I do not > > >>expect that. > > >> > > >>Considering private nature of it, it should be as specific as possible to > > >>avoid any potential conflicts with future standards. > > >>"dogtag-key-replication" > > >>sounds like a good candidate. > > > > > >IMO it shouldn't be *that* specific, considering we want to switch > > >Dogtag from SSL to GSSAPI authentication to DS, which will probably use > > >the same principal name. I think "ipa-pki/..." or "dogtag/..." should be > > >fine. > > > > (Forgot to CC Fraser.) > > > What is HTTP client support like for principal names with service > part /= "HTTP"? As a target ? None, in which case are you going to use the dogtag keytab for the acceptor though ? > For communication from IPA framework to Dogtag, > we will need a way to force the client to use an alternative service > name. Our pbox design says differently. We'll just interpose gssproxy and we'll be able to safely share the HTTP key for all services. > As for the actual service name, I will use "dogtag/..." Good to use as a client. Simo. > Cheers, > Fraser > > > > > > >> > > >>Before you set the name in stone make sure it does not conflict with > > >>anything > > >>listed on > > >>http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml > > >> > > >> > > >>These names have potential to be used by someone else. > > > > > > > -- > > Jan Cholasta > -- Simo Sorce * Red Hat, Inc * New York -- 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] [DESIGN] Sub-CAs; authenticating to Custodia
On Tue, Apr 19, 2016 at 07:48:27AM +0200, Jan Cholasta wrote: > On 14.4.2016 08:56, Jan Cholasta wrote: > >On 7.4.2016 16:17, Petr Spacek wrote: > >>On 7.4.2016 15:20, Fraser Tweedale wrote: > >>>On Thu, Apr 07, 2016 at 12:29:00PM +0200, Jan Cholasta wrote: > On 7.4.2016 12:13, Christian Heimes wrote: > >On 2016-04-07 11:09, Petr Spacek wrote: > >>On 7.4.2016 08:43, Fraser Tweedale wrote: > >>>Hi team, > >>> > >>>I updated the Sub-CAs design page with more detail for the key > >>>replication[1]. This part of the design is nearly complete (a large > >>>patchset is in review over at pki-devel@) but there are various > >>>options about how to authenticate to Custodia. > >>> > >>>[1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication > >>> > >>>In brief, the options are: > >>> > >>>1) authenticate as host principal; install binary setuid > >>>root:pkiuser to read host keytab and custodia keys. > >> > >>Huh, I really do not like this. Host keytab on IPA master is one > >>of the most > >>sensitive keys we have. > >> > >>Maybe gssproxy can be used somehow, but I think it would be better > >>to use > >>separate key. > >> > >> > >>>2) authenticate as host principal; copy host keytab and custodia > >>>keys to location readable by pkiuser. > >> > >>No, really, do not copy host keytab anywhere. > >> > >> > >>>3) create new principal for pkiuser to use, along with custodia keys > >>>and keytab in location readable by pkiuser. > >>> > >>>I prefer option (1) for reasons outlined in the design page. The > >>>design page goes into quite a bit more detail so please review the > >>>section linked above and get back to me with your thoughts. > >> > >>The only downside of (3) using new keys is: > >>... This approach requires the creation of new principals, and > >>Kerberos > >>keytabs and Custodia keys for those principals, as part of the > >>installation/upgrade process. > >> > >>Compared with additional SUID binary this seems as safer and > >>easier way to go. > >>FreeIPA installers already create quite a lot of principals and > >>keytabs so > >>this is well understood task. > >> > >>I would do (3). > > > >+1 for (3) > > > >A SUID binary feels like a dangerous hack. > > +1 > > >>>OK, (3) it is. Thanks all for your input. > >>> > >>>Now for next question: what should service principal name be? I > >>>think `dogtag/example@example.com' but am open to other > >>>suggestions, e.g. `pki/...'. > >> > >>Do you plan to attempt to standardize this name in future? I do not > >>expect that. > >> > >>Considering private nature of it, it should be as specific as possible to > >>avoid any potential conflicts with future standards. > >>"dogtag-key-replication" > >>sounds like a good candidate. > > > >IMO it shouldn't be *that* specific, considering we want to switch > >Dogtag from SSL to GSSAPI authentication to DS, which will probably use > >the same principal name. I think "ipa-pki/..." or "dogtag/..." should be > >fine. > > (Forgot to CC Fraser.) > What is HTTP client support like for principal names with service part /= "HTTP"? For communication from IPA framework to Dogtag, we will need a way to force the client to use an alternative service name. As for the actual service name, I will use "dogtag/..." Cheers, Fraser > > > >> > >>Before you set the name in stone make sure it does not conflict with > >>anything > >>listed on > >>http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml > >> > >> > >>These names have potential to be used by someone else. > > > > -- > 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] [DESIGN] Sub-CAs; authenticating to Custodia
On 14.4.2016 08:56, Jan Cholasta wrote: On 7.4.2016 16:17, Petr Spacek wrote: On 7.4.2016 15:20, Fraser Tweedale wrote: On Thu, Apr 07, 2016 at 12:29:00PM +0200, Jan Cholasta wrote: On 7.4.2016 12:13, Christian Heimes wrote: On 2016-04-07 11:09, Petr Spacek wrote: On 7.4.2016 08:43, Fraser Tweedale wrote: Hi team, I updated the Sub-CAs design page with more detail for the key replication[1]. This part of the design is nearly complete (a large patchset is in review over at pki-devel@) but there are various options about how to authenticate to Custodia. [1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication In brief, the options are: 1) authenticate as host principal; install binary setuid root:pkiuser to read host keytab and custodia keys. Huh, I really do not like this. Host keytab on IPA master is one of the most sensitive keys we have. Maybe gssproxy can be used somehow, but I think it would be better to use separate key. 2) authenticate as host principal; copy host keytab and custodia keys to location readable by pkiuser. No, really, do not copy host keytab anywhere. 3) create new principal for pkiuser to use, along with custodia keys and keytab in location readable by pkiuser. I prefer option (1) for reasons outlined in the design page. The design page goes into quite a bit more detail so please review the section linked above and get back to me with your thoughts. The only downside of (3) using new keys is: ... This approach requires the creation of new principals, and Kerberos keytabs and Custodia keys for those principals, as part of the installation/upgrade process. Compared with additional SUID binary this seems as safer and easier way to go. FreeIPA installers already create quite a lot of principals and keytabs so this is well understood task. I would do (3). +1 for (3) A SUID binary feels like a dangerous hack. +1 OK, (3) it is. Thanks all for your input. Now for next question: what should service principal name be? I think `dogtag/example@example.com' but am open to other suggestions, e.g. `pki/...'. Do you plan to attempt to standardize this name in future? I do not expect that. Considering private nature of it, it should be as specific as possible to avoid any potential conflicts with future standards. "dogtag-key-replication" sounds like a good candidate. IMO it shouldn't be *that* specific, considering we want to switch Dogtag from SSL to GSSAPI authentication to DS, which will probably use the same principal name. I think "ipa-pki/..." or "dogtag/..." should be fine. (Forgot to CC Fraser.) Before you set the name in stone make sure it does not conflict with anything listed on http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml These names have potential to be used by someone else. -- 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] [DESIGN] Sub-CAs; authenticating to Custodia
On Thu, Apr 07, 2016 at 12:29:00PM +0200, Jan Cholasta wrote: > On 7.4.2016 12:13, Christian Heimes wrote: > >On 2016-04-07 11:09, Petr Spacek wrote: > >>On 7.4.2016 08:43, Fraser Tweedale wrote: > >>>Hi team, > >>> > >>>I updated the Sub-CAs design page with more detail for the key > >>>replication[1]. This part of the design is nearly complete (a large > >>>patchset is in review over at pki-devel@) but there are various > >>>options about how to authenticate to Custodia. > >>> > >>>[1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication > >>> > >>>In brief, the options are: > >>> > >>>1) authenticate as host principal; install binary setuid > >>>root:pkiuser to read host keytab and custodia keys. > >> > >>Huh, I really do not like this. Host keytab on IPA master is one of the most > >>sensitive keys we have. > >> > >>Maybe gssproxy can be used somehow, but I think it would be better to use > >>separate key. > >> > >> > >>>2) authenticate as host principal; copy host keytab and custodia > >>>keys to location readable by pkiuser. > >> > >>No, really, do not copy host keytab anywhere. > >> > >> > >>>3) create new principal for pkiuser to use, along with custodia keys > >>>and keytab in location readable by pkiuser. > >>> > >>>I prefer option (1) for reasons outlined in the design page. The > >>>design page goes into quite a bit more detail so please review the > >>>section linked above and get back to me with your thoughts. > >> > >>The only downside of (3) using new keys is: > >>... This approach requires the creation of new principals, and Kerberos > >>keytabs and Custodia keys for those principals, as part of the > >>installation/upgrade process. > >> > >>Compared with additional SUID binary this seems as safer and easier way to > >>go. > >>FreeIPA installers already create quite a lot of principals and keytabs so > >>this is well understood task. > >> > >>I would do (3). > > > >+1 for (3) > > > >A SUID binary feels like a dangerous hack. > > +1 > OK, (3) it is. Thanks all for your input. Now for next question: what should service principal name be? I think `dogtag/example@example.com' but am open to other suggestions, e.g. `pki/...'. Cheers, Fraser -- 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] [DESIGN] Sub-CAs; authenticating to Custodia
On Thu, 2016-04-07 at 16:43 +1000, Fraser Tweedale wrote: > Hi team, > > I updated the Sub-CAs design page with more detail for the key > replication[1]. This part of the design is nearly complete (a large > patchset is in review over at pki-devel@) but there are various > options about how to authenticate to Custodia. > > [1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication > > In brief, the options are: > > 1) authenticate as host principal; install binary setuid >root:pkiuser to read host keytab and custodia keys. > > 2) authenticate as host principal; copy host keytab and custodia >keys to location readable by pkiuser. > > 3) create new principal for pkiuser to use, along with custodia keys >and keytab in location readable by pkiuser. > > I prefer option (1) for reasons outlined in the design page. The > design page goes into quite a bit more detail so please review the > section linked above and get back to me with your thoughts. I haven't read the whole design completely yet (sorry, busy with some critical bug), only the Key Replication part. We are moving toward removing access to the HTTP key from even the IPA framework, and I would definitely not want to give access to the host keytab to unprivileged processes. So I lean very heavily on (3). Simo. -- 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] [DESIGN] Sub-CAs; authenticating to Custodia
On 7.4.2016 12:13, Christian Heimes wrote: On 2016-04-07 11:09, Petr Spacek wrote: On 7.4.2016 08:43, Fraser Tweedale wrote: Hi team, I updated the Sub-CAs design page with more detail for the key replication[1]. This part of the design is nearly complete (a large patchset is in review over at pki-devel@) but there are various options about how to authenticate to Custodia. [1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication In brief, the options are: 1) authenticate as host principal; install binary setuid root:pkiuser to read host keytab and custodia keys. Huh, I really do not like this. Host keytab on IPA master is one of the most sensitive keys we have. Maybe gssproxy can be used somehow, but I think it would be better to use separate key. 2) authenticate as host principal; copy host keytab and custodia keys to location readable by pkiuser. No, really, do not copy host keytab anywhere. 3) create new principal for pkiuser to use, along with custodia keys and keytab in location readable by pkiuser. I prefer option (1) for reasons outlined in the design page. The design page goes into quite a bit more detail so please review the section linked above and get back to me with your thoughts. The only downside of (3) using new keys is: ... This approach requires the creation of new principals, and Kerberos keytabs and Custodia keys for those principals, as part of the installation/upgrade process. Compared with additional SUID binary this seems as safer and easier way to go. FreeIPA installers already create quite a lot of principals and keytabs so this is well understood task. I would do (3). +1 for (3) A SUID binary feels like a dangerous hack. +1 -- 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] [DESIGN] Sub-CAs; authenticating to Custodia
On 2016-04-07 11:09, Petr Spacek wrote: > On 7.4.2016 08:43, Fraser Tweedale wrote: >> Hi team, >> >> I updated the Sub-CAs design page with more detail for the key >> replication[1]. This part of the design is nearly complete (a large >> patchset is in review over at pki-devel@) but there are various >> options about how to authenticate to Custodia. >> >> [1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication >> >> In brief, the options are: >> >> 1) authenticate as host principal; install binary setuid >>root:pkiuser to read host keytab and custodia keys. > > Huh, I really do not like this. Host keytab on IPA master is one of the most > sensitive keys we have. > > Maybe gssproxy can be used somehow, but I think it would be better to use > separate key. > > >> 2) authenticate as host principal; copy host keytab and custodia >>keys to location readable by pkiuser. > > No, really, do not copy host keytab anywhere. > > >> 3) create new principal for pkiuser to use, along with custodia keys >>and keytab in location readable by pkiuser. >> >> I prefer option (1) for reasons outlined in the design page. The >> design page goes into quite a bit more detail so please review the >> section linked above and get back to me with your thoughts. > > The only downside of (3) using new keys is: > ... This approach requires the creation of new principals, and Kerberos > keytabs and Custodia keys for those principals, as part of the > installation/upgrade process. > > Compared with additional SUID binary this seems as safer and easier way to go. > FreeIPA installers already create quite a lot of principals and keytabs so > this is well understood task. > > I would do (3). +1 for (3) A SUID binary feels like a dangerous hack. Christian signature.asc Description: OpenPGP digital signature -- 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] [DESIGN] Sub-CAs; authenticating to Custodia
On 7.4.2016 08:43, Fraser Tweedale wrote: > Hi team, > > I updated the Sub-CAs design page with more detail for the key > replication[1]. This part of the design is nearly complete (a large > patchset is in review over at pki-devel@) but there are various > options about how to authenticate to Custodia. > > [1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication > > In brief, the options are: > > 1) authenticate as host principal; install binary setuid >root:pkiuser to read host keytab and custodia keys. Huh, I really do not like this. Host keytab on IPA master is one of the most sensitive keys we have. Maybe gssproxy can be used somehow, but I think it would be better to use separate key. > 2) authenticate as host principal; copy host keytab and custodia >keys to location readable by pkiuser. No, really, do not copy host keytab anywhere. > 3) create new principal for pkiuser to use, along with custodia keys >and keytab in location readable by pkiuser. > > I prefer option (1) for reasons outlined in the design page. The > design page goes into quite a bit more detail so please review the > section linked above and get back to me with your thoughts. The only downside of (3) using new keys is: ... This approach requires the creation of new principals, and Kerberos keytabs and Custodia keys for those principals, as part of the installation/upgrade process. Compared with additional SUID binary this seems as safer and easier way to go. FreeIPA installers already create quite a lot of principals and keytabs so this is well understood task. I would do (3). -- Petr^2 Spacek -- 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
[Freeipa-devel] [DESIGN] Sub-CAs; authenticating to Custodia
Hi team, I updated the Sub-CAs design page with more detail for the key replication[1]. This part of the design is nearly complete (a large patchset is in review over at pki-devel@) but there are various options about how to authenticate to Custodia. [1] http://www.freeipa.org/page/V4/Sub-CAs#Key_replication In brief, the options are: 1) authenticate as host principal; install binary setuid root:pkiuser to read host keytab and custodia keys. 2) authenticate as host principal; copy host keytab and custodia keys to location readable by pkiuser. 3) create new principal for pkiuser to use, along with custodia keys and keytab in location readable by pkiuser. I prefer option (1) for reasons outlined in the design page. The design page goes into quite a bit more detail so please review the section linked above and get back to me with your thoughts. Cheers, Fraser -- 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
