The OCSP response does not necessarily have to be signed by the same entity which signed the original certificate, as this responsibility can be delegated explicitly.
This is discussed in section 188.8.131.52 of RFC 2560:
184.108.40.206 Authorized Responders
The key that signs a certificate's status information need not be the
same key that signed the certificate. It is necessary however to
ensure that the entity signing this information is authorized to do
so. Therefore, a certificate's issuer MUST either sign the OCSP
responses itself or it MUST explicitly designate this authority to
another entity. OCSP signing delegation SHALL be designated by the
inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
extension included in the OCSP response signer's certificate. This
certificate MUST be issued directly by the CA that issued the
certificate in question.
Systems or applications that rely on OCSP responses MUST be capable
of detecting and enforcing use of the id-ad-ocspSigning value as
described above. They MAY provide a means of locally configuring one
or more OCSP signing authorities, and specifying the set of CAs for
which each signing authority is trusted. They MUST reject the
response if the certificate required to validate the signature on the
response fails to meet at least one of the following criteria:
Matches a local configuration of OCSP signing authority for the
certificate in question; or
Is the certificate of the CA that issued the certificate in
Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
extension and is issued by the CA that issued the certificate in
In regard to this part of your question:
I mean, isn't it enough to check if the response is signed by one of the trusted CAs in my computers?
It is critical that this is not the case, otherwise any compromised CA could falsify an OCSP response for any certificate, rather than just certificates issued by it (or delegated to it). This is not limited to public CAs; imagine the case where a company's internal CA (e.g. for use with their intranet) is compromised and used to falsify OCSP responses when users visit external websites, thus bypassing HPKP and other stapling.
Subsection 220.127.116.11.1 explains check 4; the OCSP responder must also be checked for revocation to avoid a revoked CA being able to falsify OCSP responses.