Re: [Freeipa-devel] [DESIGN] Lightweight CA renewal

2016-06-20 Thread Fraser Tweedale
On Tue, Jun 21, 2016 at 07:29:22AM +0200, Jan Cholasta wrote:
> On 18.6.2016 02:38, Fraser Tweedale wrote:
> > On Fri, Jun 17, 2016 at 03:21:07PM +0200, Jan Cholasta wrote:
> > > On 17.6.2016 09:34, Fraser Tweedale wrote:
> > > > On Mon, May 09, 2016 at 09:35:06AM +0200, Jan Cholasta wrote:
> > > > > Hi,
> > > > > 
> > > > > On 6.5.2016 08:01, Fraser Tweedale wrote:
> > > > > > Hullo all,
> > > > > > 
> > > > > > FreeIPA Lightweight CAs implementation is progressing well.  The
> > > > > > remaining big unknown in the design is how to do renewal.  I have
> > > > > > put my ideas into the design page[1] and would appreciate any and
> > > > > > all feedback!
> > > > > > 
> > > > > > [1] http://www.freeipa.org/page/V4/Sub-CAs#Renewal
> > > > > > 
> > > > > > Some brief commentary on the options:
> > > > > > 
> > > > > > I intend to implement approach (1) as a baseline.  Apart from
> > > > > > implementing machinery in Dogtag to actually perform the renewal -
> > > > > > which is required for all the approaches - it's not much work and
> > > > > > gets us over the "lightweight CAs can be renewed easily" line, even
> > > > > > if it is a manual process.
> > > > > > 
> > > > > > For automatic renewal, I am leaning towards approach (2).  Dogtag
> > > > > > owns the lightweight CAs so I think it makes sense to give Dogtag
> > > > > > the ability to renew them automatically (if configured to do so),
> > > > > > without relying on external tools i.e. Certmonger.  But as you will
> > > > > > see from the outlines, each approach has its upside and downside.
> > > > > 
> > > > > I would prefer (3), as I would very much like to avoid duplicating
> > > > > certmonger's functionality in Dogtag.
> > > > > 
> > > > > Some comments on the disadvantages:
> > > > > 
> > > > >   * "Proliferation of Certmonger tracking requests; one for each
> > > > > FreeIPA-managed lightweight CA."
> > > > > 
> > > > > I don't think this is an actual issue, as it's purely cosmetic.
> > > > > 
> > > > >   * "Either lightweight CA creation is restricted to the renewal 
> > > > > master, or
> > > > > the renewal master must observe the creation of new lightweight CAs 
> > > > > and
> > > > > start tracking their certificate."
> > > > > 
> > > > > IMO this doesn't have to be done automatically in the initial
> > > > > implementation. You could extend ipa-certupdate to set up certmonger 
> > > > > for
> > > > > lightweight CAs and have admins run it manually on masters after 
> > > > > adding a
> > > > > new lightweight CA. They will have to run it anyway to get the new
> > > > > lightweight CA certificate installed in the system, so it should be 
> > > > > fine to
> > > > > do it this way.
> > > > > 
> > > > I have updated the renew_ca_cert post-save script to perform the
> > > > database update necessary for CA replicas to pick up the new cert.
> > > > What remains is the command to tell certmonger to track the CA.
> > > > 
> > > > You mentioned ipa-certupdate but perhaps ipa-cacert-manage is a
> > > > better fit, e.g.:
> > > > 
> > > > ipa-cacert-manage track 
> > > > 
> > > > It would look up the necessary info (basically just the CA-ID) and
> > > > set up the certmonger tracking.
> > > 
> > > No. ipa-cacert-manage updates global configuration in LDAP, whereas
> > > ipa-certupdate applies the global configuration on the local system.
> > > Updating certmonger configuration is the latter, hence it should be done 
> > > in
> > > ipa-certupdate.
> > > 
> > > Also, I don't think we should expose (un)tracking certificates by CA ID to
> > > users, as all our CA certificates should always be tracked.
> > > 
> > OK, so ipa-certupdate just gets run without arguments on a CA
> > master, and it ensures that all CA certificates are tracked by
> > Certmonger.
> 
> Right.
> 
> > 
> > Makes sense to me.  Thanks for the clarifications.
> > 
> > > > 
> > > > It could be an error to run the command on other than the renewal
> > > > master.
> > > 
> > > Note that the main CA certificate is tracked on all CA servers, not just 
> > > the
> > > renewal master, otherwise it wouldn't get updated on the other CA servers
> > > after renewal. I would think the same needs to be done for lightweight CA
> > > certificates, unless there is a different mechanism for distributing the
> > > certificates to other CA masters, in which case I would prefer if the
> > > mechanism was also used for the main CA certificate.
> > > 
> > There is a different mechanism that causes other CA masters to
> > update their NSSDBs with the new certificate.  After the renewal is
> > performed, the authoritySerial attribute is updated in the
> > authority's entry in Dogtag's database; other CA replicas replicas
> > notice the update and install the new cert in their own NSSDBs
> > without requiring restart (thus, we only need to track LWCA certs on
> > the renewal master).
> > 
> > The mechanism is available on versions of Dogtag that support
> > lightweight CAs, with the ou=authorities

Re: [Freeipa-devel] [DESIGN] Lightweight CA renewal

2016-06-20 Thread Jan Cholasta

On 18.6.2016 02:38, Fraser Tweedale wrote:

On Fri, Jun 17, 2016 at 03:21:07PM +0200, Jan Cholasta wrote:

On 17.6.2016 09:34, Fraser Tweedale wrote:

On Mon, May 09, 2016 at 09:35:06AM +0200, Jan Cholasta wrote:

Hi,

On 6.5.2016 08:01, Fraser Tweedale wrote:

Hullo all,

FreeIPA Lightweight CAs implementation is progressing well.  The
remaining big unknown in the design is how to do renewal.  I have
put my ideas into the design page[1] and would appreciate any and
all feedback!

[1] http://www.freeipa.org/page/V4/Sub-CAs#Renewal

Some brief commentary on the options:

I intend to implement approach (1) as a baseline.  Apart from
implementing machinery in Dogtag to actually perform the renewal -
which is required for all the approaches - it's not much work and
gets us over the "lightweight CAs can be renewed easily" line, even
if it is a manual process.

For automatic renewal, I am leaning towards approach (2).  Dogtag
owns the lightweight CAs so I think it makes sense to give Dogtag
the ability to renew them automatically (if configured to do so),
without relying on external tools i.e. Certmonger.  But as you will
see from the outlines, each approach has its upside and downside.


I would prefer (3), as I would very much like to avoid duplicating
certmonger's functionality in Dogtag.

Some comments on the disadvantages:

  * "Proliferation of Certmonger tracking requests; one for each
FreeIPA-managed lightweight CA."

I don't think this is an actual issue, as it's purely cosmetic.

  * "Either lightweight CA creation is restricted to the renewal master, or
the renewal master must observe the creation of new lightweight CAs and
start tracking their certificate."

IMO this doesn't have to be done automatically in the initial
implementation. You could extend ipa-certupdate to set up certmonger for
lightweight CAs and have admins run it manually on masters after adding a
new lightweight CA. They will have to run it anyway to get the new
lightweight CA certificate installed in the system, so it should be fine to
do it this way.


I have updated the renew_ca_cert post-save script to perform the
database update necessary for CA replicas to pick up the new cert.
What remains is the command to tell certmonger to track the CA.

You mentioned ipa-certupdate but perhaps ipa-cacert-manage is a
better fit, e.g.:

ipa-cacert-manage track 

It would look up the necessary info (basically just the CA-ID) and
set up the certmonger tracking.


No. ipa-cacert-manage updates global configuration in LDAP, whereas
ipa-certupdate applies the global configuration on the local system.
Updating certmonger configuration is the latter, hence it should be done in
ipa-certupdate.

Also, I don't think we should expose (un)tracking certificates by CA ID to
users, as all our CA certificates should always be tracked.


OK, so ipa-certupdate just gets run without arguments on a CA
master, and it ensures that all CA certificates are tracked by
Certmonger.


Right.



Makes sense to me.  Thanks for the clarifications.



It could be an error to run the command on other than the renewal
master.


Note that the main CA certificate is tracked on all CA servers, not just the
renewal master, otherwise it wouldn't get updated on the other CA servers
after renewal. I would think the same needs to be done for lightweight CA
certificates, unless there is a different mechanism for distributing the
certificates to other CA masters, in which case I would prefer if the
mechanism was also used for the main CA certificate.


There is a different mechanism that causes other CA masters to
update their NSSDBs with the new certificate.  After the renewal is
performed, the authoritySerial attribute is updated in the
authority's entry in Dogtag's database; other CA replicas replicas
notice the update and install the new cert in their own NSSDBs
without requiring restart (thus, we only need to track LWCA certs on
the renewal master).

The mechanism is available on versions of Dogtag that support
lightweight CAs, with the ou=authorities container existing in
Dogtag's database.  It should work for the main CA, but I have not
tested this yet.


Sounds great! I hope it works, I would very much like to get rid of our 
thing now that Dogtag handles it.






An untrack command could also be provided.

Thoughts?


  * "Development of new Certmonger renewal helpers solely for lightweight CA
renewal."

It would be easier to extend the existing helpers. I don't think there
is anything preventing them from being used for lighweight CAs, except not
conveying the CA name, which should be easy to implement.


I would also avoid starting with (1), I don't believe it adds any real
value. IMHO the first thing that should be done is implement lightweight CA
support in certmonger (add new 'request' / 'start-tracking' option for CA
name, store it in tracking requests, pass it to CA helpers in a new
environment variable).


Honza

--
Jan Cholasta



--
Jan Cholasta



Re: [Freeipa-devel] [DESIGN] Lightweight CA renewal

2016-06-17 Thread Fraser Tweedale
On Fri, Jun 17, 2016 at 03:21:07PM +0200, Jan Cholasta wrote:
> On 17.6.2016 09:34, Fraser Tweedale wrote:
> > On Mon, May 09, 2016 at 09:35:06AM +0200, Jan Cholasta wrote:
> > > Hi,
> > > 
> > > On 6.5.2016 08:01, Fraser Tweedale wrote:
> > > > Hullo all,
> > > > 
> > > > FreeIPA Lightweight CAs implementation is progressing well.  The
> > > > remaining big unknown in the design is how to do renewal.  I have
> > > > put my ideas into the design page[1] and would appreciate any and
> > > > all feedback!
> > > > 
> > > > [1] http://www.freeipa.org/page/V4/Sub-CAs#Renewal
> > > > 
> > > > Some brief commentary on the options:
> > > > 
> > > > I intend to implement approach (1) as a baseline.  Apart from
> > > > implementing machinery in Dogtag to actually perform the renewal -
> > > > which is required for all the approaches - it's not much work and
> > > > gets us over the "lightweight CAs can be renewed easily" line, even
> > > > if it is a manual process.
> > > > 
> > > > For automatic renewal, I am leaning towards approach (2).  Dogtag
> > > > owns the lightweight CAs so I think it makes sense to give Dogtag
> > > > the ability to renew them automatically (if configured to do so),
> > > > without relying on external tools i.e. Certmonger.  But as you will
> > > > see from the outlines, each approach has its upside and downside.
> > > 
> > > I would prefer (3), as I would very much like to avoid duplicating
> > > certmonger's functionality in Dogtag.
> > > 
> > > Some comments on the disadvantages:
> > > 
> > >   * "Proliferation of Certmonger tracking requests; one for each
> > > FreeIPA-managed lightweight CA."
> > > 
> > > I don't think this is an actual issue, as it's purely cosmetic.
> > > 
> > >   * "Either lightweight CA creation is restricted to the renewal master, 
> > > or
> > > the renewal master must observe the creation of new lightweight CAs and
> > > start tracking their certificate."
> > > 
> > > IMO this doesn't have to be done automatically in the initial
> > > implementation. You could extend ipa-certupdate to set up certmonger for
> > > lightweight CAs and have admins run it manually on masters after adding a
> > > new lightweight CA. They will have to run it anyway to get the new
> > > lightweight CA certificate installed in the system, so it should be fine 
> > > to
> > > do it this way.
> > > 
> > I have updated the renew_ca_cert post-save script to perform the
> > database update necessary for CA replicas to pick up the new cert.
> > What remains is the command to tell certmonger to track the CA.
> > 
> > You mentioned ipa-certupdate but perhaps ipa-cacert-manage is a
> > better fit, e.g.:
> > 
> > ipa-cacert-manage track 
> > 
> > It would look up the necessary info (basically just the CA-ID) and
> > set up the certmonger tracking.
> 
> No. ipa-cacert-manage updates global configuration in LDAP, whereas
> ipa-certupdate applies the global configuration on the local system.
> Updating certmonger configuration is the latter, hence it should be done in
> ipa-certupdate.
> 
> Also, I don't think we should expose (un)tracking certificates by CA ID to
> users, as all our CA certificates should always be tracked.
> 
OK, so ipa-certupdate just gets run without arguments on a CA
master, and it ensures that all CA certificates are tracked by
Certmonger.

Makes sense to me.  Thanks for the clarifications.

> > 
> > It could be an error to run the command on other than the renewal
> > master.
> 
> Note that the main CA certificate is tracked on all CA servers, not just the
> renewal master, otherwise it wouldn't get updated on the other CA servers
> after renewal. I would think the same needs to be done for lightweight CA
> certificates, unless there is a different mechanism for distributing the
> certificates to other CA masters, in which case I would prefer if the
> mechanism was also used for the main CA certificate.
> 
There is a different mechanism that causes other CA masters to
update their NSSDBs with the new certificate.  After the renewal is
performed, the authoritySerial attribute is updated in the
authority's entry in Dogtag's database; other CA replicas replicas
notice the update and install the new cert in their own NSSDBs
without requiring restart (thus, we only need to track LWCA certs on
the renewal master).

The mechanism is available on versions of Dogtag that support
lightweight CAs, with the ou=authorities container existing in
Dogtag's database.  It should work for the main CA, but I have not
tested this yet.

> > 
> > An untrack command could also be provided.
> > 
> > Thoughts?
> > 
> > >   * "Development of new Certmonger renewal helpers solely for lightweight 
> > > CA
> > > renewal."
> > > 
> > > It would be easier to extend the existing helpers. I don't think there
> > > is anything preventing them from being used for lighweight CAs, except not
> > > conveying the CA name, which should be easy to implement.
> > > 
> > > 
> > > I would also avoid sta

Re: [Freeipa-devel] [DESIGN] Lightweight CA renewal

2016-06-17 Thread Jan Cholasta

On 17.6.2016 09:34, Fraser Tweedale wrote:

On Mon, May 09, 2016 at 09:35:06AM +0200, Jan Cholasta wrote:

Hi,

On 6.5.2016 08:01, Fraser Tweedale wrote:

Hullo all,

FreeIPA Lightweight CAs implementation is progressing well.  The
remaining big unknown in the design is how to do renewal.  I have
put my ideas into the design page[1] and would appreciate any and
all feedback!

[1] http://www.freeipa.org/page/V4/Sub-CAs#Renewal

Some brief commentary on the options:

I intend to implement approach (1) as a baseline.  Apart from
implementing machinery in Dogtag to actually perform the renewal -
which is required for all the approaches - it's not much work and
gets us over the "lightweight CAs can be renewed easily" line, even
if it is a manual process.

For automatic renewal, I am leaning towards approach (2).  Dogtag
owns the lightweight CAs so I think it makes sense to give Dogtag
the ability to renew them automatically (if configured to do so),
without relying on external tools i.e. Certmonger.  But as you will
see from the outlines, each approach has its upside and downside.


I would prefer (3), as I would very much like to avoid duplicating
certmonger's functionality in Dogtag.

Some comments on the disadvantages:

  * "Proliferation of Certmonger tracking requests; one for each
FreeIPA-managed lightweight CA."

I don't think this is an actual issue, as it's purely cosmetic.

  * "Either lightweight CA creation is restricted to the renewal master, or
the renewal master must observe the creation of new lightweight CAs and
start tracking their certificate."

IMO this doesn't have to be done automatically in the initial
implementation. You could extend ipa-certupdate to set up certmonger for
lightweight CAs and have admins run it manually on masters after adding a
new lightweight CA. They will have to run it anyway to get the new
lightweight CA certificate installed in the system, so it should be fine to
do it this way.


I have updated the renew_ca_cert post-save script to perform the
database update necessary for CA replicas to pick up the new cert.
What remains is the command to tell certmonger to track the CA.

You mentioned ipa-certupdate but perhaps ipa-cacert-manage is a
better fit, e.g.:

ipa-cacert-manage track 

It would look up the necessary info (basically just the CA-ID) and
set up the certmonger tracking.


No. ipa-cacert-manage updates global configuration in LDAP, whereas 
ipa-certupdate applies the global configuration on the local system. 
Updating certmonger configuration is the latter, hence it should be done 
in ipa-certupdate.


Also, I don't think we should expose (un)tracking certificates by CA ID 
to users, as all our CA certificates should always be tracked.




It could be an error to run the command on other than the renewal
master.


Note that the main CA certificate is tracked on all CA servers, not just 
the renewal master, otherwise it wouldn't get updated on the other CA 
servers after renewal. I would think the same needs to be done for 
lightweight CA certificates, unless there is a different mechanism for 
distributing the certificates to other CA masters, in which case I would 
prefer if the mechanism was also used for the main CA certificate.




An untrack command could also be provided.

Thoughts?


  * "Development of new Certmonger renewal helpers solely for lightweight CA
renewal."

It would be easier to extend the existing helpers. I don't think there
is anything preventing them from being used for lighweight CAs, except not
conveying the CA name, which should be easy to implement.


I would also avoid starting with (1), I don't believe it adds any real
value. IMHO the first thing that should be done is implement lightweight CA
support in certmonger (add new 'request' / 'start-tracking' option for CA
name, store it in tracking requests, pass it to CA helpers in a new
environment variable).


Honza

--
Jan Cholasta



--
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] Lightweight CA renewal

2016-06-17 Thread Fraser Tweedale
On Mon, May 09, 2016 at 09:35:06AM +0200, Jan Cholasta wrote:
> Hi,
> 
> On 6.5.2016 08:01, Fraser Tweedale wrote:
> > Hullo all,
> > 
> > FreeIPA Lightweight CAs implementation is progressing well.  The
> > remaining big unknown in the design is how to do renewal.  I have
> > put my ideas into the design page[1] and would appreciate any and
> > all feedback!
> > 
> > [1] http://www.freeipa.org/page/V4/Sub-CAs#Renewal
> > 
> > Some brief commentary on the options:
> > 
> > I intend to implement approach (1) as a baseline.  Apart from
> > implementing machinery in Dogtag to actually perform the renewal -
> > which is required for all the approaches - it's not much work and
> > gets us over the "lightweight CAs can be renewed easily" line, even
> > if it is a manual process.
> > 
> > For automatic renewal, I am leaning towards approach (2).  Dogtag
> > owns the lightweight CAs so I think it makes sense to give Dogtag
> > the ability to renew them automatically (if configured to do so),
> > without relying on external tools i.e. Certmonger.  But as you will
> > see from the outlines, each approach has its upside and downside.
> 
> I would prefer (3), as I would very much like to avoid duplicating
> certmonger's functionality in Dogtag.
> 
> Some comments on the disadvantages:
> 
>   * "Proliferation of Certmonger tracking requests; one for each
> FreeIPA-managed lightweight CA."
> 
> I don't think this is an actual issue, as it's purely cosmetic.
> 
>   * "Either lightweight CA creation is restricted to the renewal master, or
> the renewal master must observe the creation of new lightweight CAs and
> start tracking their certificate."
> 
> IMO this doesn't have to be done automatically in the initial
> implementation. You could extend ipa-certupdate to set up certmonger for
> lightweight CAs and have admins run it manually on masters after adding a
> new lightweight CA. They will have to run it anyway to get the new
> lightweight CA certificate installed in the system, so it should be fine to
> do it this way.
> 
I have updated the renew_ca_cert post-save script to perform the
database update necessary for CA replicas to pick up the new cert.
What remains is the command to tell certmonger to track the CA.

You mentioned ipa-certupdate but perhaps ipa-cacert-manage is a
better fit, e.g.:

ipa-cacert-manage track 

It would look up the necessary info (basically just the CA-ID) and
set up the certmonger tracking.

It could be an error to run the command on other than the renewal
master.

An untrack command could also be provided.

Thoughts?

>   * "Development of new Certmonger renewal helpers solely for lightweight CA
> renewal."
> 
> It would be easier to extend the existing helpers. I don't think there
> is anything preventing them from being used for lighweight CAs, except not
> conveying the CA name, which should be easy to implement.
> 
> 
> I would also avoid starting with (1), I don't believe it adds any real
> value. IMHO the first thing that should be done is implement lightweight CA
> support in certmonger (add new 'request' / 'start-tracking' option for CA
> name, store it in tracking requests, pass it to CA helpers in a new
> environment variable).
> 
> 
> Honza
> 
> -- 
> 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] Lightweight CA renewal

2016-05-10 Thread Jan Cholasta

On 9.5.2016 18:27, Petr Vobornik wrote:

On 05/09/2016 09:35 AM, Jan Cholasta wrote:

Hi,

On 6.5.2016 08:01, Fraser Tweedale wrote:

Hullo all,

FreeIPA Lightweight CAs implementation is progressing well.  The
remaining big unknown in the design is how to do renewal.  I have
put my ideas into the design page[1] and would appreciate any and
all feedback!

[1] http://www.freeipa.org/page/V4/Sub-CAs#Renewal

Some brief commentary on the options:

I intend to implement approach (1) as a baseline.  Apart from
implementing machinery in Dogtag to actually perform the renewal -
which is required for all the approaches - it's not much work and
gets us over the "lightweight CAs can be renewed easily" line, even
if it is a manual process.

For automatic renewal, I am leaning towards approach (2).  Dogtag
owns the lightweight CAs so I think it makes sense to give Dogtag
the ability to renew them automatically (if configured to do so),
without relying on external tools i.e. Certmonger.  But as you will
see from the outlines, each approach has its upside and downside.


I would prefer (3), as I would very much like to avoid duplicating
certmonger's functionality in Dogtag.

Some comments on the disadvantages:

  * "Proliferation of Certmonger tracking requests; one for each
FreeIPA-managed lightweight CA."

I don't think this is an actual issue, as it's purely cosmetic.

  * "Either lightweight CA creation is restricted to the renewal master,
or the renewal master must observe the creation of new lightweight CAs
and start tracking their certificate."

IMO this doesn't have to be done automatically in the initial
implementation. You could extend ipa-certupdate to set up certmonger for
lightweight CAs and have admins run it manually on masters after adding
a new lightweight CA. They will have to run it anyway to get the new
lightweight CA certificate installed in the system, so it should be fine
to do it this way.


I'm afraid that it can lead to errors where admins would distribute the
cert by other means and as a result this command would not be run on
renewal master even though it is easier. But it is still better than #1
without auto-renewal mechanism.


Admins can screw up using any of the proposed approaches, so IMHO this 
argument is invalid :-)






  * "Development of new Certmonger renewal helpers solely for
lightweight CA renewal."

It would be easier to extend the existing helpers. I don't think
there is anything preventing them from being used for lighweight CAs,
except not conveying the CA name, which should be easy to implement.


I would also avoid starting with (1), I don't believe it adds any real
value. IMHO the first thing that should be done is implement lightweight
CA support in certmonger (add new 'request' / 'start-tracking' option
for CA name, store it in tracking requests, pass it to CA helpers in a
new environment variable).


Honza




--
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] Lightweight CA renewal

2016-05-09 Thread Petr Vobornik
On 05/09/2016 09:35 AM, Jan Cholasta wrote:
> Hi,
> 
> On 6.5.2016 08:01, Fraser Tweedale wrote:
>> Hullo all,
>>
>> FreeIPA Lightweight CAs implementation is progressing well.  The
>> remaining big unknown in the design is how to do renewal.  I have
>> put my ideas into the design page[1] and would appreciate any and
>> all feedback!
>>
>> [1] http://www.freeipa.org/page/V4/Sub-CAs#Renewal
>>
>> Some brief commentary on the options:
>>
>> I intend to implement approach (1) as a baseline.  Apart from
>> implementing machinery in Dogtag to actually perform the renewal -
>> which is required for all the approaches - it's not much work and
>> gets us over the "lightweight CAs can be renewed easily" line, even
>> if it is a manual process.
>>
>> For automatic renewal, I am leaning towards approach (2).  Dogtag
>> owns the lightweight CAs so I think it makes sense to give Dogtag
>> the ability to renew them automatically (if configured to do so),
>> without relying on external tools i.e. Certmonger.  But as you will
>> see from the outlines, each approach has its upside and downside.
> 
> I would prefer (3), as I would very much like to avoid duplicating
> certmonger's functionality in Dogtag.
> 
> Some comments on the disadvantages:
> 
>   * "Proliferation of Certmonger tracking requests; one for each
> FreeIPA-managed lightweight CA."
> 
> I don't think this is an actual issue, as it's purely cosmetic.
> 
>   * "Either lightweight CA creation is restricted to the renewal master,
> or the renewal master must observe the creation of new lightweight CAs
> and start tracking their certificate."
> 
> IMO this doesn't have to be done automatically in the initial
> implementation. You could extend ipa-certupdate to set up certmonger for
> lightweight CAs and have admins run it manually on masters after adding
> a new lightweight CA. They will have to run it anyway to get the new
> lightweight CA certificate installed in the system, so it should be fine
> to do it this way.

I'm afraid that it can lead to errors where admins would distribute the
cert by other means and as a result this command would not be run on
renewal master even though it is easier. But it is still better than #1
without auto-renewal mechanism.

> 
>   * "Development of new Certmonger renewal helpers solely for
> lightweight CA renewal."
> 
> It would be easier to extend the existing helpers. I don't think
> there is anything preventing them from being used for lighweight CAs,
> except not conveying the CA name, which should be easy to implement.
> 
> 
> I would also avoid starting with (1), I don't believe it adds any real
> value. IMHO the first thing that should be done is implement lightweight
> CA support in certmonger (add new 'request' / 'start-tracking' option
> for CA name, store it in tracking requests, pass it to CA helpers in a
> new environment variable).
> 
> 
> Honza
> 
-- 
Petr Vobornik

-- 
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] Lightweight CA renewal

2016-05-09 Thread Jan Cholasta

Hi,

On 6.5.2016 08:01, Fraser Tweedale wrote:

Hullo all,

FreeIPA Lightweight CAs implementation is progressing well.  The
remaining big unknown in the design is how to do renewal.  I have
put my ideas into the design page[1] and would appreciate any and
all feedback!

[1] http://www.freeipa.org/page/V4/Sub-CAs#Renewal

Some brief commentary on the options:

I intend to implement approach (1) as a baseline.  Apart from
implementing machinery in Dogtag to actually perform the renewal -
which is required for all the approaches - it's not much work and
gets us over the "lightweight CAs can be renewed easily" line, even
if it is a manual process.

For automatic renewal, I am leaning towards approach (2).  Dogtag
owns the lightweight CAs so I think it makes sense to give Dogtag
the ability to renew them automatically (if configured to do so),
without relying on external tools i.e. Certmonger.  But as you will
see from the outlines, each approach has its upside and downside.


I would prefer (3), as I would very much like to avoid duplicating 
certmonger's functionality in Dogtag.


Some comments on the disadvantages:

  * "Proliferation of Certmonger tracking requests; one for each 
FreeIPA-managed lightweight CA."


I don't think this is an actual issue, as it's purely cosmetic.

  * "Either lightweight CA creation is restricted to the renewal 
master, or the renewal master must observe the creation of new 
lightweight CAs and start tracking their certificate."


IMO this doesn't have to be done automatically in the initial 
implementation. You could extend ipa-certupdate to set up certmonger for 
lightweight CAs and have admins run it manually on masters after adding 
a new lightweight CA. They will have to run it anyway to get the new 
lightweight CA certificate installed in the system, so it should be fine 
to do it this way.


  * "Development of new Certmonger renewal helpers solely for 
lightweight CA renewal."


It would be easier to extend the existing helpers. I don't think 
there is anything preventing them from being used for lighweight CAs, 
except not conveying the CA name, which should be easy to implement.



I would also avoid starting with (1), I don't believe it adds any real 
value. IMHO the first thing that should be done is implement lightweight 
CA support in certmonger (add new 'request' / 'start-tracking' option 
for CA name, store it in tracking requests, pass it to CA helpers in a 
new environment variable).



Honza

--
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


[Freeipa-devel] [DESIGN] Lightweight CA renewal

2016-05-05 Thread Fraser Tweedale
Hullo all,

FreeIPA Lightweight CAs implementation is progressing well.  The
remaining big unknown in the design is how to do renewal.  I have
put my ideas into the design page[1] and would appreciate any and
all feedback!

[1] http://www.freeipa.org/page/V4/Sub-CAs#Renewal

Some brief commentary on the options:

I intend to implement approach (1) as a baseline.  Apart from
implementing machinery in Dogtag to actually perform the renewal -
which is required for all the approaches - it's not much work and
gets us over the "lightweight CAs can be renewed easily" line, even
if it is a manual process.

For automatic renewal, I am leaning towards approach (2).  Dogtag
owns the lightweight CAs so I think it makes sense to give Dogtag
the ability to renew them automatically (if configured to do so),
without relying on external tools i.e. Certmonger.  But as you will
see from the outlines, each approach has its upside and downside.

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