> That's a pointless goal to try and solve right now, because the SSL
> PKI cannot handle compromised web servers and so neither can we (with
> v1 of the payments spec).

I don't think the OP intended to solve it "right now", i.e. in v1.

He differentiated between "most trusted" and "less trusted" keys
(certs). So he can clearly live with the SSL PKI being "less trusted"
for his purpose.

Yes, but my point is if the SSL key lives on the web server, and there are CAs that issue you certs based on control of a web server at the given domain name (there are), then you can simply issue yourself a new SSL cert with whatever data in it you want and pose as the merchant.

So I don't see how you can have a payment request signing key that's safer than an SSL key. As Jeremy notes, CAs will not issue you intermediate certificates. Perhaps if one existed that would do the necessary things for a reasonable price you could indeed give yourself an offline intermediate cert and then use that to sign one cert for SSL and another for payment request signing, but as far as anyone is aware no such CA exists.

The interesting case is where the thing signing payment requests is less trusted than the web server. The scenario you're trying to solve is the inverse - the payment request signing process is more trusted than the web server. But unless/until the CA landscape changes we don't have a way to implement that.