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?
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).
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
> It does make senes.
>
> In regards to *this* patch, I will make -mod behave the same as -del
> and -disable; i.e. the current behaviour i.e. revoke whenever we
> "forget" a certificate.
>
> Any config knobs, command options, etc to govern whether to revoke
> shall be added in a subsequent patch.
--
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
