[Freeipa-devel] [PATCH 0014] Support multiple user and host certificates

[Simo Sorce]

On Thu, 2015-05-28 at 15:43 +0200, Martin Kosek wrote:
> On 05/28/2015 02:29 PM, Petr Spacek wrote:
> > On 28.5.2015 12:06, Fraser Tweedale wrote:
> >> On Thu, May 28, 2015 at 11:52:25AM +0200, Martin Kosek wrote:
> >>> On 05/28/2015 11:17 AM, Martin Basti wrote:
> >>>> On 28/05/15 10:46, Martin Kosek wrote:
> >>>>> On 05/27/2015 06:12 PM, Martin Basti wrote:
> >>>>>> On 27/05/15 15:53, Fraser Tweedale wrote:
> >>>>>>> This patch adds supports for multiple user / host certificates.  No
> >>>>>>> schema change is needed ('usercertificate' attribute is already
> >>>>>>> multi-value).  The revoke-previous-cert behaviour of host-mod and
> >>>>>>> user-mod has been removed but revocation behaviour of -del and
> >>>>>>> -disable is preserved.
> >>>>>>>
> >>>>>>> The latest profiles/caacl patchset (0001..0013 v5) depends on this
> >>>>>>> patch for correct cert-request behaviour.
> >>>>>>>
> >>>>>>> There is one design question (or maybe more, let me know): the
> >>>>>>> `--out=FILENAME' option to {host,service} show saves ONE certificate
> >>>>>>> to the named file.  I propose to either:
> >>>>>>>
> >>>>>>> a) write all certs, suffixing suggested filename with either a
> >>>>>>>      sequential numerical index, e.g. "cert.pem" becomes
> >>>>>>>      "cert.pem.1", "cert.pem.2", and so on; or
> >>>>>>>
> >>>>>>> b) as above, but suffix with serial number and, if there are
> >>>>>>>      different issues, some issuer-identifying information.
> >>>>>>>
> >>>>>>> Let me know your thoughts.
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> Fraser
> >>>>>>>
> >>>>>>>
> >>>>>> Is there a possible way how to store certificates into one file?
> >>>>>> I read about possibilities to have multiple certs in one .pem file, but I'm not
> >>>>>> cert guru :)
> >>>>>>
> >>>>>> I personally vote for serial number in case there are multiple certificates, if
> >>>>>> ^ is no possible.
> >>>>>>
> >>>>>>
> >>>>>> 1)
> >>>>>> +            if len(certs) > 0:
> >>>>>>
> >>>>>> please use only,
> >>>>>> if certs:
> >>>>>>
> >>>>>> 2)
> >>>>>> You need to re-generate API/ACI.txt in this patch
> >>>>>>
> >>>>>> 3)
> >>>>>> syntax error:
> >>>>>> +        for dercert in certs_der
> >>>>>>
> >>>>>>
> >>>>>> 4)
> >>>>>> command
> >>>>>> ipa user-mod ca_user --certificate=<ceritifcate>
> >>>>>>
> >>>>>> removes the current certificate from the LDAP, by design.
> >>>>>> Should be the old certificate(s) revoked? You removed that part in the code.
> >>>>> Good question. I think the suggestion was to have a global switch in IPA global
> >>>>> config that would configure the policy - whether the certificates removed by
> >>>>> this command or by host-del or host-disable are revoked or if they are just
> >>>>> removed (my motivation is to avoid behavior regression in case somebody
> >>>>> depended on this behavior).
> >>>> I would prefer to keep the current behavior: revoke the certificate if it was
> >>>> replaced or removed, instead of adding an extra configuration option.
> >>>> This behavior is not regression.
> >>>
> >>> It is not. However, it is not an ideal behavior also. In FreeIPA 4.2, we are
> >>> now adding support of certificate profiles, multiple certificates and even
> >>> certificates for user.
> >>>
> >>> With that change, there may be much more certificates in play than now. If we
> >>> keep revoking all such certificates, it may cause rapid growth of CRLs. This is
> >>> something I am trying to avoid with this proposal and default to not revoking
> >>> certificates automatically (which mostly only makes sense if there is a risk
> >>> that the key is compromised), but have some option to keep the old behavior.
> >>>
> >>> Does this make sense?
> > 
> > I would like to see some data to support the decision not to revoke certs by
> > default. Are there some facts to base the decision on? Or just hand-wavy
> > reasoning?
> 
> What facts would you like to hear? If we are speaking from bugs, we already
> know that large CRL lists caused lot of grief to deployments with bug
> host/service turnaround. I do not have more data than this, besides my
> expectation that there may be much more certificates tracked by FreeIPA than in
> the past and we need to deal with it.
> 
> > Sure, huge CRL may be bad, but not revoking certs may be even worse. E.g. when
> > older backup files are stolen (in the information sense, i.e. copied without
> > anyone noticing it) - attacker might get valid certs despite the fact that the
> > old cert is never used (because it was rotated right after the backup).
> 
> I am not convinced that this is a valid point. We cannot assume that FreeIPA
> administrator leaks certificate keys and try to magically fix that by this
> policy. Such fault backup can leak even when the host/service still exists.
> 
> This is about what makes most sense for certificate handling, what is the
> secure behavior and a behavior that most administrators would expect (thus the
> default). Are you sure revoking all deleted certificates is the expected
> behavior? In my mind, certificates are being revoked from more serious reasons
> - when employee "leaves" a company, machine (or it's backup) is compromised,
> etc. But in that case admin would use cert-revoke command.
> 
> Let me also CC Rob - do we know why FreeIPA was implemented to revoke all
> service/host certificates by default on deletion/disable?

+1 Martin, by default you assume minimally competent admins that do not
leak private key. If you cannot assume that then you have already lost,
revoking certs will help nothing as there are a ton of certs and keytabs
that can be used by an attacker and are still valid then.
In general Revocations are used when there is a real chance a private
key have been compromised because they are costly.

Simo.