Re: Proposal for implementing OCSP Stapling in PostgreSQL

Thanks a lot Jacob for helping update the tests and sorry for the late
reply.

Based on previous discussion, I remove the document patch, and start to
focus on the v1 simple OCSP logic by checking the leaf/Postgres server
certificate's status only
(0001-v1-WIP-OCSP-support-certificate-status-check.patch). I also merge
your changes and simplify the test by testing the Postgres server
certificate's status only
(0002-v1-WIP-OCSP-simplify-.res-generation-and-regress-tes.patch).

On 2024-07-18 10:18 a.m., Jacob Champion wrote:
>>> A question from ignorance: how does the client decide that the
>>> signature on the OCSP response is actually valid for the specific
>>> chain in use?
>> If I understand correctly, the certificate used by the OCSP responder to
>> sign the OCSP response must be valid for the specific chain in use, or
>> the admins allow to load a new chain to validate the certificate used to
>> sign the OCSP response. I think it would be better to make this part to
>> be more open.
> Okay. That part needs more design work IMO, and solid testing.
Based on the RFC here,
https://datatracker.ietf.org/doc/html/rfc6960#section-4.2.2.2. My
understanding is that the OCSP responder's certificate should be
directly signed by the same CA which signed the Postgres Server's
certificate. It looks the openssl 3.0.14 implements in this way. In
other words, it the OCSP responder's certificate is signed by a
different branch of the chain, then openssl will report some errors.
Unless the end user explicitly provides the OCSP responder's certificate
with trust_other option. In this case it will skip the some certificate
verification. I think it should be simple enough for v1 by set
`OCSP_basic_verify(basic_resp, NULL, trusted_store, 0)`.  The key
function OCSP_basic_verify is documented at here,
https://docs.openssl.org/3.0/man3/OCSP_resp_find_status/

Thank you,
David