[BLOG/DESIGN] cert-request revocation changes

[Fraser Tweedale]

Hi all,

Ticket https://pagure.io/freeipa/issue/7482 made me think about the
current revocation behaviour in `ipa cert-request`.  For hosts and
services, all old certificates get revoked.

I wrote a blog post[1] outlining the problems with the current
behaviour, and some suggested changes.  I'd like to know others'
thoughts.  If we go ahead it would be something for a major release,
not a bugfix release.  The actual amount of work is pretty small.

[1]
https://frasertweedale.github.io/blog-redhat/posts/2018-05-11-renewal-and...

Thanks,
Fraser

[Simo Sorce]

On Fri, 2018-05-11 at 15:47 +1000, Fraser Tweedale via FreeIPA-devel
wrote:
>  Hi all,
>  
>  Ticket https://pagure.io/freeipa/issue/7482 made me think about the
>  current revocation behaviour in `ipa cert-request`.  For hosts and
>  services, all old certificates get revoked.
>  
>  I wrote a blog post[1] outlining the problems with the current
>  behaviour, and some suggested changes.  I'd like to know others'
>  thoughts.  If we go ahead it would be something for a major release,
>  not a bugfix release.  The actual amount of work is pretty small.
>  
>  [1]
> https://frasertweedale.github.io/blog-redhat/posts/2018-05-11-renewal-and...
I'd prefer no revocation by default, if people need two+ certs with the
same name they should be able to do so easily (for example for
clustered services that need to answer as a single machine).

It also fills a CRL list for no good reasons, we should be conservative
on CRL size, and if someone has a dynamic environment where hosts are
created and destroyed frequently the CRL could become enormous.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc

[Rob Crittenden]

Simo Sorce wrote:
>  On Fri, 2018-05-11 at 15:47 +1000, Fraser Tweedale via FreeIPA-devel
>  wrote:
> > Hi all,
> >
> > Ticket https://pagure.io/freeipa/issue/7482 made me think about the
> > current revocation behaviour in `ipa cert-request`.  For hosts and
> > services, all old certificates get revoked.
> >
> > I wrote a blog post[1] outlining the problems with the current
> > behaviour, and some suggested changes.  I'd like to know others'
> > thoughts.  If we go ahead it would be something for a major release,
> > not a bugfix release.  The actual amount of work is pretty small.
> >
> > [1]
> https://frasertweedale.github.io/blog-redhat/posts/2018-05-11-renewal-and...
>  
>  I'd prefer no revocation by default, if people need two+ certs with the
>  same name they should be able to do so easily (for example for
>  clustered services that need to answer as a single machine). 
Multiple certs is fine but the convention to date has been one cert per 
service so that usage can be more easily tracked. If they want that can 
have a single cert and share it everywhere but then things are more 
opaque and the systems harder to manage. You can't easily answer the 
question "What TLS services are we running on bob?"

I can't quite get my head around Fraser's scenario Certificate for new 
purpose (non-renewal). New purpose for the same service? Do you have any 
examples of that?

Beyond the fact that we'll have to come up with some other scheme to 
sift the database looking for expired certs to remove from usercertificate.

Remember that storing usercertificate in host/service entries provides 
really no value whatsoever except to pin the fact that the service has a 
certificate at all. So being able to store 0, 1 or more doesn't really 
buy you a lot unless you are using these services to bind as clients.

Even now when you display a service it provides the details for only ONE 
certificate.

user certs are another story altogether and not covered here.

>  It also fills a CRL list for no good reasons, we should be
> conservative
>  on CRL size, and if someone has a dynamic environment where hosts are
>  created and destroyed frequently the CRL could become enormous. 
Sure, assuming they actually use the CRL or OCSP.

I'd be ok making it a config option.

I think I'd rather not extend the cert-request API for the revocation 
case and use post-command scripts to do it instead. This is an IPA 
policy so it should live within IPA.

rob

[Fraser Tweedale]

On Fri, May 11, 2018 at 01:52:57PM -0400, Rob Crittenden via FreeIPA-devel wrote:
>  Simo Sorce wrote:
>  > On Fri, 2018-05-11 at 15:47 +1000, Fraser Tweedale via FreeIPA-devel
>  > wrote:
>  > > Hi all,
>  > > 
>  > > Ticket https://pagure.io/freeipa/issue/7482 made me think about the
>  > > current revocation behaviour in `ipa cert-request`.  For hosts and
>  > > services, all old certificates get revoked.
>  > > 
>  > > I wrote a blog post[1] outlining the problems with the current
>  > > behaviour, and some suggested changes.  I'd like to know others'
>  > > thoughts.  If we go ahead it would be something for a major release,
>  > > not a bugfix release.  The actual amount of work is pretty small.
>  > > 
>  > > [1]
> https://frasertweedale.github.io/blog-redhat/posts/2018-05-11-renewal-and...
>  > 
>  > I'd prefer no revocation by default, if people need two+ certs with the
>  > same name they should be able to do so easily (for example for
>  > clustered services that need to answer as a single machine).
>  
>  Multiple certs is fine but the convention to date has been one cert per
>  service so that usage can be more easily tracked. If they want that can have
>  a single cert and share it everywhere but then things are more opaque and
>  the systems harder to manage. You can't easily answer the question "What TLS
>  services are we running on bob?"
>  
>  I can't quite get my head around Fraser's scenario Certificate for new
>  purpose (non-renewal). New purpose for the same service? Do you have any
>  examples of that?
>   
(Not a concrete example, but anyway...) Some service principal needs
a TLS server certificate, and a client certificate to connect to
some backend service, which needs a special Extended Key Usage value
(or whatever).

>  Beyond the fact that we'll have to come up with some other scheme
> to sift
>  the database looking for expired certs to remove from usercertificate.
>  
We already have a ticket to add a command (or command options) for
pruning expired certs: https://pagure.io/freeipa/issue/7219
We could add it to the certmonger helper to get automatic pruning
for certmonger-tracked certs.

>  Remember that storing usercertificate in host/service entries
> provides
>  really no value whatsoever except to pin the fact that the service has a
>  certificate at all. So being able to store 0, 1 or more doesn't really buy
>  you a lot unless you are using these services to bind as clients.
>   
Do we know what customer expectations are around this?  (BTW,
whether to store issued certs in principal's userCertificate
attribute is a profile-specific configuration).

>  Even now when you display a service it provides the details for only
> ONE
>  certificate.
>   
That's a bug IMO.

>  user certs are another story altogether and not covered here.
>  
>  > It also fills a CRL list for no good reasons, we should be conservative
>  > on CRL size, and if someone has a dynamic environment where hosts are
>  > created and destroyed frequently the CRL could become enormous.
>  
>  Sure, assuming they actually use the CRL or OCSP.
>  
>  I'd be ok making it a config option.
>  
>  I think I'd rather not extend the cert-request API for the revocation case
>  and use post-command scripts to do it instead. This is an IPA policy so it
>  should live within IPA.
>  
Fair enough.  I didn't feel strongly either way.

Rob & Simo, thanks for your feedback!  I'll write up a proper design
proposal later this week.

Thanks,
Fraser

[Petr Vobornik]

On Mon, May 14, 2018 at 4:47 AM, Fraser Tweedale <ftweedal(a)redhat.com&gt; wrote:
>  On Fri, May 11, 2018 at 01:52:57PM -0400, Rob Crittenden via
> FreeIPA-devel wrote:
> > Simo Sorce wrote:
> > > On Fri, 2018-05-11 at 15:47 +1000, Fraser Tweedale via FreeIPA-devel
> > > wrote:
> > > > Hi all,
> > > >
> > > > Ticket https://pagure.io/freeipa/issue/7482 made me think about the
> > > > current revocation behaviour in `ipa cert-request`.  For hosts and
> > > > services, all old certificates get revoked.
> > > >
> > > > I wrote a blog post[1] outlining the problems with the current
> > > > behaviour, and some suggested changes.  I'd like to know others'
> > > > thoughts.  If we go ahead it would be something for a major release,
> > > > not a bugfix release.  The actual amount of work is pretty small.
> > > >
> > > > [1]
> https://frasertweedale.github.io/blog-redhat/posts/2018-05-11-renewal-and...
> > >
> > > I'd prefer no revocation by default, if people need two+ certs with the
> > > same name they should be able to do so easily (for example for
> > > clustered services that need to answer as a single machine).
> >
> > Multiple certs is fine but the convention to date has been one cert per
> > service so that usage can be more easily tracked. If they want that can have
> > a single cert and share it everywhere but then things are more opaque and
> > the systems harder to manage. You can't easily answer the question "What
> TLS
> > services are we running on bob?"
> >
> > I can't quite get my head around Fraser's scenario Certificate for new
> > purpose (non-renewal). New purpose for the same service? Do you have any
> > examples of that?
> >
>  (Not a concrete example, but anyway...) Some service principal needs
>  a TLS server certificate, and a client certificate to connect to
>  some backend service, which needs a special Extended Key Usage value
>  (or whatever).
>
> > Beyond the fact that we'll have to come up with some other scheme to sift
> > the database looking for expired certs to remove from usercertificate.
> >
>  We already have a ticket to add a command (or command options) for
>  pruning expired certs: https://pagure.io/freeipa/issue/7219
>  We could add it to the certmonger helper to get automatic pruning
>  for certmonger-tracked certs.
>
> > Remember that storing usercertificate in host/service entries provides
> > really no value whatsoever except to pin the fact that the service has a
> > certificate at all. So being able to store 0, 1 or more doesn't really buy
> > you a lot unless you are using these services to bind as clients.
> >
>  Do we know what customer expectations are around this?  (BTW,
>  whether to store issued certs in principal's userCertificate
>  attribute is a profile-specific configuration).
>
> > Even now when you display a service it provides the details for only ONE
> > certificate.
> >
>  That's a bug IMO. 
And only partly correct. Web UI shows all certificates. CLI, though,
shows all certificates as a blob and details(issuer, serial number,
...) only for one certificate.

Otherwise, management of multiple certs is in IPA since 4.2.
https://www.freeipa.org/page/V4/User_Certificates - this was also the
reason for the changed revocation behavior.

For adding non-FreeIPA issued certs, there is:

{host,service,user}-add-cert

For removal:
{host,service,user}-host-remove-cert

Which for hosts and services also calls cert-revoke for certs with IPA
CA or Sub-CA.

This (revoke removed IPA issued cert) revocation behavior is also in
{host,service}-mod.

For displaying details of arbitrary cert, there is:
$ ipa cert-find --certificate=CERTIFICATE

(Which IMO should have been a separate command, but that is another discussion).


> > user certs are another story altogether and not covered here.
> >
> > > It also fills a CRL list for no good reasons, we should be conservative
> > > on CRL size, and if someone has a dynamic environment where hosts are
> > > created and destroyed frequently the CRL could become enormous.
> >
> > Sure, assuming they actually use the CRL or OCSP.
> >
> > I'd be ok making it a config option.
> >
> > I think I'd rather not extend the cert-request API for the revocation case
> > and use post-command scripts to do it instead. This is an IPA policy so it
> > should live within IPA.
> >
>  Fair enough.  I didn't feel strongly either way.
>
>  Rob & Simo, thanks for your feedback!  I'll write up a proper design
>  proposal later this week.
>
>  Thanks,
>  Fraser 


-- 
Petr Vobornik

[Simo Sorce]

On Fri, 2018-05-11 at 13:52 -0400, Rob Crittenden wrote:
>  Simo Sorce wrote:
>  > On Fri, 2018-05-11 at 15:47 +1000, Fraser Tweedale via FreeIPA-devel
>  > wrote:
>  > > Hi all,
>  > > 
>  > > Ticket https://pagure.io/freeipa/issue/7482 made me think about the
>  > > current revocation behaviour in `ipa cert-request`.  For hosts and
>  > > services, all old certificates get revoked.
>  > > 
>  > > I wrote a blog post[1] outlining the problems with the current
>  > > behaviour, and some suggested changes.  I'd like to know others'
>  > > thoughts.  If we go ahead it would be something for a major release,
>  > > not a bugfix release.  The actual amount of work is pretty small.
>  > > 
>  > > [1]
> https://frasertweedale.github.io/blog-redhat/posts/2018-05-11-renewal-and...
>  > 
>  > I'd prefer no revocation by default, if people need two+ certs with the
>  > same name they should be able to do so easily (for example for
>  > clustered services that need to answer as a single machine).
>  
>  Multiple certs is fine but the convention to date has been one cert per 
>  service so that usage can be more easily tracked. If they want that can 
>  have a single cert and share it everywhere but then things are more 
>  opaque and the systems harder to manage. You can't easily answer the 
>  question "What TLS services are we running on bob?" 
I am not sure this is such a huge winner though.
First of all that tracking is expensive for our directory, and we
should think if it is worth.

A lot of systems have certs not IPA based anyway (public certs, private
domain specific CAs, etc... so IPA is not the source of all truth for
TLS certs anyway.

>  I can't quite get my head around Fraser's scenario
> Certificate for new 
>  purpose (non-renewal). New purpose for the same service? Do you have any 
>  examples of that? 
Simple cases are needing certs for both Apache, Postfix and IMAP, all
sharing the same name for ease of configuration by mail clients.

Also think about load balancers serving behind a DNS round robin
service, and they have HSMs
It is more ideal to have multiple certs in that case thn copying around
private keys.
This is a bit out there, but in general not sharing the key when
multiple services use the same name is a win.
(for example if only one system is compromised you can revoke that
system's specific cert and not have to take a full outage to rotate
cert and keys on all systems, etc...)

>  Beyond the fact that we'll have to come up with some other scheme
> to 
>  sift the database looking for expired certs to remove from usercertificate. 
Not sure I understand this point

>  Remember that storing usercertificate in host/service entries
> provides 
>  really no value whatsoever except to pin the fact that the service has a 
>  certificate at all. So being able to store 0, 1 or more doesn't really 
>  buy you a lot unless you are using these services to bind as clients.
>  
>  Even now when you display a service it provides the details for only ONE 
>  certificate. 
I would not store the cert unless we have a good reason for it.
I would think dogtag can already do tracking and we do not need to do
it again in DS.

>  user certs are another story altogether and not covered here.
>  
>  > It also fills a CRL list for no good reasons, we should be conservative
>  > on CRL size, and if someone has a dynamic environment where hosts are
>  > created and destroyed frequently the CRL could become enormous.
>  
>  Sure, assuming they actually use the CRL or OCSP.
>  
>  I'd be ok making it a config option.
>  
>  I think I'd rather not extend the cert-request API for the revocation 
>  case and use post-command scripts to do it instead. This is an IPA 
>  policy so it should live within IPA. 
Is it a IPA policy ? Or should it be controlled by admins ?

I think I am getting in the camp that admins/cert owners should decide
if they want to revoke a cert. Doing it automatically has some
benefits, but in time I came around to think the negatives are more
than the positives.

Simo.

-- 
Simo Sorce
Sr. Principal Software Engineer
Red Hat, Inc