@mow
First of all, thank you for the reply - I like this kind of in-depth discussions, since they do add value, even to the Plesk forum.
In my humble opinion, a rock-solid discussion is a good starting point to come to a roadmap for future development ..... come to something in agreement.
In essence, this is often what lacks in terms of Plesk development : certain things are to be expected, but still not anticipated.
For instance, the current (annoying) issue with OCSP stapling is one the "things not anticipated", even though it could have been expected since 2022.
The statement
But you need to get that information somehow if you want to be able to revoke certificates at all.
is a bit lopsided, in the sense that revocation is not a process.
Revocation is simply the endresult of renewal a specific certificate.
Revocation is hence a product of the process of renewal.
More importantly, revocation by design (and intention) is a product that allows for security checks.
In theory, there is no need to do anything with revoked certificates, since the process of renewal would simply suffice.
In practice, there is a desire (not a need) to do something with revoked certificates, since that can increase security by various methods - for instance, dbases with revoked certificates allow for "easy" validity checking and/or allow for identifying abuse of certificates (for malicious purposes).
Nevertheless, a desire is totally different from a need.
In addition, desires are mostly driven by other objectives, which objectives might be commercial (i.e. related to efficiency and lower cost, not to security).
In every way, all new developments are to some degree subject to a commercial goal related to "obtaining or maintaining market share".
The big debate between (original) OCSP and OCSP Stapling was more or less a battlefield for market share between browsers .... and to a lesser degree, between larger and smaller CAs with less resources and hence bigger difficulties to satisfy the (original) OCSP requirements, since (original) OCSP can be deemed to be associated with a bigger number of requests than OCSP Stapling.
Moreover, all new developments are prone to one party or a group of parties dominating the roadmap of development.
OCSP Stapling has been presented as the solution to some well-known issues with (original) OCSP and pushed as a solution by many parties.
However, this is actually solving a problem, without noticing the root cause of the problem.
The actual root cause of the problem is a combination of the factors that
1 - all expired certificates can be considered as "unvalid" (and CRLs are the solution to that, since CRLs contain a lot of information)
2 - not all unexpired certificates are "valid" (and the only solution to that is composed of validation requests with the CA)
3 - unexpired certificates can be stored as revoked certificates (and both original OCSP and OCSP Stapling are a solution to that)
4 - revoked certificates can be checked efficiently by means of OCSP Stapling (since original OCSP is just as demanding as regular validation methods)
5 - OCSP Stapling data does not include a lot of data (and CRLs do, so CRLs are to be preferred)
6 - OCSP Stapling data only includes data about validity (or revocation) FROM THE LAST TIME the OCSP service has been contacted
7 - OCSP Stapling can create a small or big time frame in which a certificate may seem to be valid (but actually is not)
8 - OCSP Stapling is just as good (or safe) as the client contacting the OCSP service (and some clients only check for revocation, not for validity)
In summary, there is a big desire (or even need) to prevent huge numbers of requests with the CAs and OCSP Stapling was proposed as a solution.
However, there are considerable underlying problems when focusing on "revoked certificates" with either OCSP or OCSP Stapling.
Even though (original) OCSP and OCSP Stapling create efficiency in the sense that
a) the number of requests with the CA is narrowed down to unexpired certificates,
b) the number of requests with (original) OCSP is narrowed down to expired certificates, with requests being less demanding than CRL requests,
c) the number of requests with OCSP Stapling is narrowed down to expired certificates, with requests being less demanding than (original) OCSP requests,
there still is the concern of safety and security, related to the time frame in which a certificate may seem valid (but actually might not be valid).
The latter security issue really depends on the implementation used, i.e. the client.
For instance, Let's Encrypt / SSL it! extension in Plesk - essentially - uses OCSP Stapling to determine the time at which a certificate has to be renewed.
There is a desire to do that, but there is no need to implement it in a different way : most browsers still use CRL based validation methods, implying that any certificate that is renewed on time by Plesk will be accepted by a browser (since the renewed certificate is not in a CRL).
As another example, using OCSP Stapling (or OCSP) to determine whether the certificate has been revoked, does not imply that you check for validity : in all cases, a validity check with the CA still has to be done in order to establish validity of the certificate.
There is a need to do that validity check, since unexpired certificates are NOT automatically valid.
The latter need also becomes clear when one realizes that OCSP Stapling will result in a (small or big) time window in which a certificate can seem valid.
In general, there is always a need (not a desire) to check for validity with the CA.
In my humble opinion, moving far away from validity checks by emphasizing revocation checks is wrong by nature and design.
And we are all exposed to the consequences thereof, as has become painfully clear when one Microsoft certificate was issued to an unknown person.
Deciding to impose CAs with a lesser burden for the sake of efficiency for only those CAs, that is a very odd and wrong trade-off between public security and commercial gain as a result of increased efficiency and associated lower costs.
I have never been a fan of (original) OCSP, given the presence of CRLs ...... and could not be a fan of OCSP Stapling, for many reasons.
It really should be a process of "check" (revocation) and "double check" (validity).
Kind regards....
PS I am not mentioning, for the sake of convenience and clarity, that OCSP Stapling and/or OCSP are significantly affecting security in many ways that are or can be very negative. OCSP Stapling or (original) OCSP are intended and designed to have a positive effect on security, but the opposite is also true. In a brief nutshell, the dynamic nature of OCSP and OCSP Stapling allows for "certificate data harvesting" with that data making it more "easy" (read: not easy, but not impossible) to hack and/or falsify certificates. CRLs have a similar disadvantage to a much lesser degree, due to the static nature of CRLs. Difficult topic!
PS 2 For the sake of convenience, I am not quoting the four points mentioned by
@mow, since they should be addressed to a high degree in all of the above.
Facebook
Twitter
