Hi Daniel,
Thank you for all the information.
On 2024-08-07 12:20 a.m., Daniel Gustafsson wrote:
While I have only skimmed the patch so far and need more review before I can
comment on it, I do have a question on the expected use of OCSP support in
postgres. With OCSP becoming optional [0], and big providers like Let's
Encrypt deprecating OCSP [1], is this mainly targeting organizations running
their own CA with in-house OCSP?
--
Daniel Gustafsson
[0]
https://lists.cabforum.org/pipermail/servercert-wg/2023-September/003998.html
[1] https://letsencrypt.org/2024/07/23/replacing-ocsp-with-crls.html
Regarding the privacy concert, the OCSP Stapling works in a very similar
way as CRL but provide a more "real-time" certificate status checking.
When the Client/psql needs to check the Certificate Status using OCSP
Stapling, it doesn't connect to any 3rd party server, such as CA or OCSP
Responder. It only requires the Server/Postgres to provide one extra
piece of information about the status of Server's certificate. OCSP
Stapling was designed to avoid the privacy concern and a single point of
failure issues.
When the Client/psql needs to check the certificate revocation status:
option 1 using CRL: CA generates the CRL and then upload it to somewhere
or distribute it to each Client/psql. I think Postgres only support the
preloaded CRL.
option 2 using OCSP Stapling: Postgres server retrieves the certificate
status periodically from OCSP responder, the Client/psql will do the
certificate status check during each handshake.
I think it is still necessary to provide the 2nd option/flexibility to
end users if they are allowed to check the Postgres server's certificate
revocation status through CRL.
Thank you,
David
