freeipa

FreeIPA is an integrated Identity and Authentication solution for Linux/UNIX networked environments.  |  http://www.freeipa.org/

#3951 [RFE] ECC Support for the CA

Created 3 years ago by meesvirk
Modified 4 months ago

FreeIPA should support ECC algorithms for the CA features in addition to the RSA. This should be preferably be offered out of the box as an option.

A brief overview on the practical impact of choosing between RSA and ECC can be read from for example RFC 4492:

   Elliptic Curve Cryptography (ECC) is emerging as an attractive
   public-key cryptosystem, in particular for mobile (i.e., wireless)
   environments.  Compared to currently prevalent cryptosystems such as
   RSA, ECC offers equivalent security with smaller key sizes.  This is
   illustrated in the following table, based on [18], which gives
   approximate comparable key sizes for symmetric- and asymmetric-key
   cryptosystems based on the best-known algorithms for attacking them.

                    Symmetric  |   ECC   |  DH/DSA/RSA
                   ------------+---------+-------------
                        80     |   163   |     1024
                       112     |   233   |     2048
                       128     |   283   |     3072
                       192     |   409   |     7680
                       256     |   571   |    15360

                  Table 1: Comparable Key Sizes (in bits)

   Smaller key sizes result in savings for power, memory, bandwidth, and
   computational cost that make ECC especially attractive for
   constrained environments.

Not only more efficient today, ECC will probably withstand the future developments in cryptoanalysis better. Many crypto systems such as SSL/TLS certificates are used to protect important data for long periods of time, at least until the data has lost its value already. For some information this can mean decades.

To counter-balance the projected advancements one of the main mitigation tools used is increasing the key sizes. Alas, this can not be done very far with RSA. Several embedded platforms such as smart cards will start failing to function rapidly as the key sizes increase. For example RSA smart cards will typically start failing at between 3-5 kilobits. ECC algorithms will fare better on limited hardware.

FreeIpa should, to ensure longevity of the product, implement ECC as soon as possible. It is one of the major features that will in the near future start impacting product selection for CA applications.

Jan, I checked caIPAserviceCert.cfg and this will indeed require a change in the profile (as we discussed):

...
policyset.serverCertSet.8.constraint.params.signingAlgsAllowed=SHA1withRSA,SHA256withRSA,SHA512withRSA, MD5withRSA,MD2withRSA,SHA1withDSA,SHA1withEC,SHA256withEC,SHA384withEC,SHA512withEC
...

ECC is now officially available in Fedora, see the result in Bug 319901 (and the related juicy discussion). We can now reconsider when to introduce the support (at least signing ECC certificates).

I am thinking we may do it along with #3977 - another cert profile change.

The FreeIPA 4.2 was already shaped (see [[milestone:FreeIPA 4.2]] milestone), this does not fit. Pushing out.

If anyone is willing to help and contribute to this one, please let us know!

See https://fedorahosted.org/pki/ticket/2291 (Support Lightweight CA key replication with non-RSA host authority). This is a prerequisite to supporting EC CA in FreeIPA.

6 months ago

Metadata Update from @meesvirk:
- Issue assigned to ftweedal
- Issue set to the milestone: FreeIPA 4.5 backlog

Cedric Parent was successfully able to get a working FreeIPA with ECC with following change to cainstance.py:

# diff -u /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py{-orig,}
--- /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py-orig    2017-03-30 08:38:50.119093054 +0000
+++ /usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py    2017-03-30 08:39:16.137097947 +0000
@@ -511,7 +511,11 @@
         config.set("CA", "pki_ca_signing_nickname", "caSigningCert cert-pki-ca")

         # CA key algorithm
-        config.set("CA", "pki_ca_signing_key_algorithm", self.ca_signing_algorithm)
+        config.set("CA", "pki_ca_signing_signing_algorithm", "SHA256withEC")
+        config.set("CA", "pki_ca_signing_key_algorithm", "SHA256withEC")
+        config.set("CA", "pki_ca_signing_key_size", "nistp256")
+        config.set("CA", "pki_ca_signing_key_type", "ecc")

         if self.clone:

Then he just needed to make a change in respective certprofile:

policyset.serverCertSet.3.constraint.params.keyParameters=nistp521,secp521r1
policyset.serverCertSet.3.constraint.params.keyType=EC

to make signing ECC certificates also work.

4 months ago

Metadata Update from @mkosek:
- Issue close_status updated to: None

This is not enough, though. We need to ensure that following is in place:

  • when a master is configured, ECC or RSA for the root certificate can be chosen via installer
  • when a replica is promoted, it inherits global ECC/RSA state
  • certmonger should chose proper defaults for ECC/RSA based on a CA cert properties. Right now ECC cipher is chosen based on the size of RSA key requested, we should do better and instead allow setting a proper curve and default to a reasonable curve.
  • Configuration should not prevent using both ECC and RSA in TLS negotiation for Apache and LDAP servers in case there are both types of certificates available.
  • Care should be taken for cases when externally provided certificates for users (PKINIT, etc) are using different signing algorithms' family. At the very least there should be detection of such cases and clear error/warning indication.

Login to comment on this ticket.

enhancement

Certificate management

0

https://bugzilla.redhat.com/show_bug.cgi?id=1326411

cancel