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

[Petr Spacek]

On 28.5.2015 15:43, 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.

"We had bugs about big CRLs" is good enough. I wanted to be sure that this is
not a premature optimization.

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

I'm curious too. My expectation is that if admin deletes a user then the user
cannot use his password for authentication anymore, even if admin did not use
user-lock command prior the deletion. So the same behavior for certs seems
quite natural for me.

Anyway, the information above that it causes real problems is good enough for me.

Thank you for your patience with me.

Petr^2 Spacek

>> IMHO this behavior should be configurable and default to 'revoke'. We should
>> ship FreeIPA with secure defaults and let users to lower the standards if they
>> wish/need.
>>
>> Petr^2 Spacek