On Thu, Apr 25, 2013 at 12:45:33PM +0200, Mike Hearn wrote:
>     > 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.

True, I forgot about that, though we already had discussed this in the

Timo Hanke
PGP AB967DA8, Key fingerprint = 1EFF 69BC 6FB7 8744 14DB  631D 1BB5 D6E3 AB96 

Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
Bitcoin-development mailing list

Reply via email to