From: Timo Hanke <timo.hanke@web•de>
To: Mike Hearn <mike@plan99•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Cold Signing Payment Requests
Date: Thu, 25 Apr 2013 12:28:53 +0200 [thread overview]
Message-ID: <20130425102853.GA31573@crunch> (raw)
In-Reply-To: <CANEZrP3EhS3-HnPT_exc9MjZn-ywZggSzqSHPzHU5J2EZuLQtg@mail.gmail.com>
On Thu, Apr 25, 2013 at 12:05:06PM +0200, Mike Hearn wrote:
> Chaining a custom cert onto the end doesn't work, at least not if your
> "end" is the SSL cert. Chaining it to the SSL cert defeats the OP's
> intention of "cold signing", as the SSL private key is usually kept
> online, therefore can't be used to sign a pubkey that is supposed to stay offline.
i meant: ^whose privkey is supposed to stay offline.
> the goal of all this is not to protect against web server compromise.
> The goal of this is to allow delegation of signing authority without giving the
> delegate the SSL private key.
This is not how I understand the OP, which I said I was addressing:
> The difficulty is that Payment Requests must be generated live, and
> therefore the key used to sign those requests must also be live,
> exposing the key to theft similar to a hot wallet. Steal the key,
> forge payment requests, and the payer sees a 'green box' but the coins
> go to the attacker. The question... is there a way to sign something
> once, with a key kept offline, which verifies the address in the
> Payment Request belongs to the payee?
> 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.
--
Timo Hanke
PGP AB967DA8, Key fingerprint = 1EFF 69BC 6FB7 8744 14DB 631D 1BB5 D6E3 AB96 7DA8
next prev parent reply other threads:[~2013-04-25 10:29 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 [this message]
2013-04-25 10:45 ` Mike Hearn
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=20130425102853.GA31573@crunch \
--to=timo.hanke@web$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/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