On 28/05/15 14:29, 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.


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.

+            if len(certs) > 0:

please use only,
if certs:

You need to re-generate API/ACI.txt in this patch

syntax error:
+        for dercert in certs_der

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

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

Petr^2 Spacek

would be enought to have just option in the command --revoke-cert=true, with true as default, instead of global configuration?

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.

Martin Basti

Manage your subscription for the Freeipa-devel mailing list:
Contribute to FreeIPA: http://www.freeipa.org/page/Contribute/Code

Reply via email to