Re: Proposal for implementing OCSP Stapling in PostgreSQL

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