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):
caIPAserviceCert.cfg
... 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!
Taking ownership. Discussion: https://www.redhat.com/archives/freeipa-devel/2015-September/msg00341.html
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=1326411
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.
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:
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.
Metadata Update from @mkosek: - Issue close_status updated to: None
This is not enough, though. We need to ensure that following is in place:
Engineering work is needed in JSS and Dogtag too, to support LWCA key replication with non-RSA main CA keypair.
Metadata Update from @ftweedal: - Custom field component reset (from Certificate management) - Custom field on_review reset (from 0) - Custom field rhbz reset (from https://bugzilla.redhat.com/show_bug.cgi?id=1326411) - Custom field type reset (from enhancement)
Login to comment on this ticket.