Some statements were misleading or vague, as we discussed in #34 , these are my suggestions to better inform any future readers of that README section.
Closes: https://github.com/breard-r/acmed/issues/34
@ -113,10 +113,10 @@ An example service file is provided (see `acmed.service.example`). The file migh
It depends on your definition of a beginner. This software is intended to be used by system administrator with a certain knowledge of their environment. Furthermore, it is also expected to know the bases of the ACME protocol. Let's Encrypt wrote a nice article about [how it works](https://letsencrypt.org/how-it-works/).
It depends on your definition of a beginner. This software is intended to be used by system administrator with a certain knowledge of their environment. Furthermore, it is also expected to know the bases of the ACME protocol. Let's Encrypt wrote a nice article about [how it works](https://letsencrypt.org/how-it-works/).
### Why is RSA2048 the default?
### Why is RSA-2048 the default?
Despite the fact that RSA 4096, ECDSA P-256 and ECDSA P-384 are supported, those are not (yet) fitted to be the default choice.
It might surprise you, but [larger key sizes for RSA has diminishing returns in security](https://danielpocock.com/rsa-key-sizes-2048-or-4096-bits/). In fact, RSA-4096 adds [a lot more calculation while providing only a small security improvement](https://www.gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096).
It is not obvious at the first sight, but [RSA 4096](https://gnupg.org/faq/gnupg-faq.html#no_default_of_rsa4096) is NOT twice more secure than RSA 2048. In fact, it adds a lot more calculation while providing only a small security improvement. If you think you will use it anyway since you are more concerned about security than performance, please check your certificate chain up to the root. Most of the time, the root certificate and the intermediates will be RSA 2048 ones (that is the case for [Let’s Encrypt](https://letsencrypt.org/certificates/)). If so, using RSA4096 in the final certificate will not add any additional security since a system's global security level is equal to the level of its weakest point.
If you think you will use it anyway since you are more concerned about security than performance, please check your certificate chain up to the root. Most of the time, the root certificate and the intermediates will be RSA 2048 ones (that is the case for [Let’s Encrypt](https://letsencrypt.org/certificates/)). If so, using RSA-4096 in the final certificate will not add any additional security since a system's global security level is equal to the level of its weakest point, except on legacy clients when using cipher suites that lack [Perfect Forward Secrecy](https://en.wikipedia.org/wiki/Forward_secrecy#Protocols).
ECDSA certificates may be a good alternative to RSA since, for the same security level, they are smaller and requires less computation, hence improve performance. Unfortunately, as X.509 certificates may be used in various contexts, some software may not support this not-so-recent technology. To achieve maximal compatibility while using ECC, you usually have to set-up an hybrid configuration with both an ECDSA and a RSA certificate to fall-back to. Therefore, even if you are encouraged to use ECDSA certificates, it should not currently be the default. That said, it may be in a soon future.
ECDSA certificates may be a good alternative to RSA since, for the same [security level]((https://www.ssl.com/article/comparing-ecdsa-vs-rsa/#key-size-to-security-level-ratio), they are smaller and require less computation, hence improved performance. As X.509 certificates may be used in various contexts, [some legacy software may lack support](https://support.globalsign.com/ssl/ssl-certificates-life-cycle/ecc-compatibility). You could configure your server to [provide an ECDSA certificate with an RSA certificate as fallback](https://scotthelme.co.uk/hybrid-rsa-and-ecdsa-certificates-with-nginx/).