It's not about OCSP. It's about the fact that you are displaying wilful ignorance.
Well, at least I'm not lying.
Mind please that up in this topic, yet today, at least two different people (both supporters of your SSL based payment protocol) stated clearly that the verification process involves sending a hash of a transaction to the CA.
Links? I could only find one, and I have no idea why he thinks that anything related to the transaction would ever be sent to the CA.
Given the circumstance in which the CA system produces the signature for the Payment Request message, how can a valid signature be produced that the CA did not sign?
Ahh. The problem then is that you don't know how SSL PKI works.
The CA generates a private key, and a matching public key. The pubkey is packaged into a certificate, which is then signed by the privkey (which is funny, because it is a self-signature, but it still provides some assurances). They then publish that certificate.
The merchant generates their own private key and the matching pubkey. They package that into a certificate with some identifying information, which is sent to the CA. The CA signs the merchant certificate with their private key and sends it back.
The merchant then generates a payment request, hashes it, and signs the hash with their private key.
You get the request, the signature and the certificate. Your software verifies that the attached certificate does indeed correspond to the signature.
To verify that the certificate you are looking at does indeed belong to the vendor you think it belongs to, your client checks that the certificate it received has been signed by a trusted CA. In this simple example, the CA's published pubkey has been included in the client through some out-of-band mechanism (hardcoded into the source maybe).
You will notice that at no time during your transaction is anything sent to the CA. The CA isn't signing your specific message, they already signed the merchant's certificate, and the merchant's private key is used to sign the request.
There are two wrinkles that can be added to the simple example. The first is when the CA doesn't sign your certificate directly. In that case, the merchant sends a
certificate chain. Your client then follows the chain backwards, making sure that the merchant's cert has been signed by X, and that X was signed by Y, and so on until certificate Z was signed by the CA.
The second is OCSP. In OCSP, your client can look in the merchant certificate for a field specifying the OCSP server. Your client can then ask the OCSP server if the certificate it is looking at is still valid. If the certificate was signed in error, or if the private key for it was stolen from a compromised server, you can find that out in real time using OCSP, and potentially reject the transaction despite having valid signatures.
(There is also a variation of OCSP called OCSP stapling where the server, rather than the client, requests proof of validity from the OCSP server and attaches it to the certificate. This is better for privacy, since your client doesn't then need to tell the CA that someone from IP address X is checking on the certificate issued to Y. OCSP already has a timestamp and a validity window, and are signed, so it doesn't really matter who asks for it or which servers it passes through in transit.)
