Out of a set of 94 characters each character represents about 6.55 bits of entropy
where of a set of 64 characters each character represents about 6.0 bits of entropy
and of a set of 32 characters each character represents about 5.0 bits of entropy
So yes length is more important than complexity and frequency, still best to keep a nondeterministic method for selecting the next character to be used.
IMHO the discourse about key rotation and security is irrelevant. The keys do not have to be rotated every 90 days by the ACME spec or by LetsEncrypt/ISRG. The 90 day rotation "single use" key is just the default behavior of Certbot and several other popular clients. Nearly every client that I know of supports re-using keys (including Certbot), and Posh-ACME reuses them by default.
As others have said - 90 day expiration is important because of deficiencies in the certificate revocation system; the short lived certs will be ever better.
You can implement whatever key rotation policies you want, just change clients if yours does not support your preferred security policy.
I suppose I ask a naïve question, but if a private key is not compromised (i.e. not in the possession of someone who does not legitimately control a domain name or IP address or whatever identifier), for what purpose is revocation? I just don't see how a leaf certificate can be of any functional use to anyone (legitimate or otherwise) without possession of its private key. Am I missing something? To me, this all seems like a key management problem.
Perhaps I should phrase it this way: IMO other than meeting some possibly arbitrary and/or esoteric requirements (i.e. clerical error) about date stamps or such, to me the entire "controversy" around revocation comes down to whether or not a private key should be considered "legitimate" for a leaf certificate.
In terms of security and sometimes legal/contractual compliance, Revocation ensures the above can not happen. If you consider the mere existence of an unexpired ancillary certificate a liability and potential security concern, revocation ensures that any backups of a "destroyed" private key are unusable.
To me that sounds like "potential" key compromise, otherwise said key could simply be used to issue another certificate with the same functional use as the revoked certificate, right? In essence, it sounds like the key is what is being revoked, not the certificate, in a sense.
Not all revocations are the same, we like to say it's only ever needed in case of keyCompromise but there's other possible reasons that invalidate the signature but not the key itself like keyCompromise does.
A private key and cert could have been valid at one point, but then the domain/IP gets controlled by another party. So the key isn't "compromised" in the sense that someone else has it, but the holder of the key could in theory intercept packets and spoof to a client that they still control the name, even though they actually no longer do. Other than the subscriber agreement saying that a holder is obligated to revoke once they no longer control the name, there isn't really any technical constraints to stop that sort of thing other than moving to shorter-duration certificates.
I forgot about this case. 
Thanks for reminding me. A lifetime greater than zero will still, of course, allow this situation, but at least a shorter lifetime will reduce the window of vulnerability. I wonder how small the window needs to be to determine that revocation is no longer needed.
I vaguely remember some discussions about this, either here or on mdsp. In an ideal world, a certificate would only be valid for a single connection, i.e. it is issued in real time and used as a nonce. Its "validity" would thus be use-constrained and not time-constrained, with its real time of use being only a handful of milliseconds. This provides the best security against compromise.
However, this ideal world doesn't scale in the real world: Asking CAs to perform real-time validations for billions of TLS connections per second is just not feasible at all (both in terms of server capacity and latency considerations). Thus, we have to compromise: How much time do you want to allow, before the downsides of a short lifetime outweigh the benefits? Determining this isn't an exact science: These decisions are based mainly on uptime considerations: An admin should have an opportunity to fix an issue.
Back in 2015, Mozilla decided that they do not care about revocation for certificates valid for less than 10 days. Later this was formalized into the shortlived servercert-wg proposal, where discussions resulted in a figure that decided on a 7-day value - which is now what's being used by major root programs. The discussion around the exact value to use, and its implications has been going on since at least 2014: https://groups.google.com/g/mozilla.dev.security.policy/c/T11up58JkFc/m/Nph-8cFiuEMJ
I am not a cryptographer so my apologies if this is a dumb question. Isn't the initial key exchange and authentication the most susceptible phase of the whole process? So by shortening the lifetime you are increasing the risk by adding this step more frequently?
The question isn't dumb, and there is indeed some truth to it. However, it isn't the full picture either.
It is true that the handshake (key exchange + authentication) is the fundamental basis on which the second phase (transport encryption+authentication) is built. If the handshake is broken, then you cannot rely on anything else that follows after.
However, there is no (direct) relationship between the lifetime of a certificate and the frequency of handshakes. A TLS handshake is usually* performed every time a new TCP connection is established, e.g. every time the user visits a website they haven't visited in the last few minutes. TLS handshakes are a very common operation anyway, even if your cert is three years valid the full process has to be run every time, to establish fresh cryptographic keys for the subsequent session. Thus the lifetime of the certificate has little to no relevance to the TLS handshake security model.
The security model of transport security protocols like TLS is such that the number of handshakes performed has only negligible impact on security. The main thought in cryptographic protocols is that "if you can break one, you can break all". Thus, the security level is held up so high such that the handshake can (ideally) never be broken, therefore it also doesn't matter how many handshakes are executed. There is some mathematical degradation over time, i.e. if you were to theoretically perform 2^128 handshakes you suddenly have a non-negligible probability of secret value collisions, which is a problem. But even if you were to execute 1 quintillion (10^18) handshakes per second, it would take you 780 * the current age of the universe to reach those numbers - the sun will be long, long gone before you need to worry about these numbers.
To sum up, there is no risk (as in, a probability that is relevant over the lifetime of a human being) that would increase.
*Ignoring TLS resumption here, but resumption lifetimes are much smaller than certificate lifetimes and typically also unrelated.
Thanks for the clarification.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.