From: Mike Hearn <mike@plan99•net>
To: timo.hanke@web•de
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Cold Signing Payment Requests
Date: Thu, 25 Apr 2013 12:45:33 +0200 [thread overview]
Message-ID: <CANEZrP1343gX-utnbO16Z6axMDMmvYpiGXW8_Vc-yec03ip=1g@mail.gmail.com> (raw)
In-Reply-To: <20130425102853.GA31573@crunch>
[-- Attachment #1: Type: text/plain, Size: 1436 bytes --]
>
> > 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.
[-- Attachment #2: Type: text/html, Size: 1861 bytes --]
next prev parent reply other threads:[~2013-04-25 10:45 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.38128.1366844895.4905.bitcoin-development@lists.sourceforge.net>
2013-04-25 9:58 ` Timo Hanke
2013-04-25 10:05 ` Mike Hearn
2013-04-25 10:28 ` Timo Hanke
2013-04-25 10:45 ` Mike Hearn [this message]
2013-04-25 10:52 ` Mike Hearn
2013-04-25 11:55 ` Timo Hanke
[not found] ` <FDF215AE-F9A4-4EE3-BDC9-0A4EF027423A@swipeclock.com>
2013-04-25 14:31 ` Mike Hearn
2013-04-25 19:12 ` Jeremy Spilman
2013-04-26 1:07 ` Gavin Andresen
2013-04-28 18:03 ` Timo Hanke
2013-04-29 18:40 ` Jeremy Spilman
2013-04-30 9:17 ` Mike Hearn
2013-04-30 11:32 ` Jouke Hofman
2013-04-30 13:14 ` Gavin Andresen
2013-04-30 17:17 ` Jeremy Spilman
2013-05-06 21:29 ` Peter Todd
2013-04-24 23:01 Jeremy Spilman
2013-04-24 23:07 ` Alan Reiner
2013-04-25 9:08 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CANEZrP1343gX-utnbO16Z6axMDMmvYpiGXW8_Vc-yec03ip=1g@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=timo.hanke@web$(echo .)de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox