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:52:33 +0200 [thread overview]
Message-ID: <CANEZrP340hjkf8CyUnGBznRdGJWfxoAYmFOuTGbT8=pg2DNA+g@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP1343gX-utnbO16Z6axMDMmvYpiGXW8_Vc-yec03ip=1g@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1248 bytes --]
>
> 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.
>
Re-reading what I wrote, it's not really clear.
Even if possible, the intermediate cert setup still wouldn't work for most
merchants but I didn't make that clear. It might work for EV certs. For
most sites that are just DV there's nothing you can do because CA
verification is just "do you control this domain name". So if your web
server is compromised it's game over. They can issue themselves a new cert,
and what's more, unless wallets are checking revocation lists you can't
stop them signing as you until their certificate expires.
The process for getting an EV cert is harder and there, an offline
restricted intermediate cert might make more sense because you could have a
compromised SSL key whilst not having a compromised identity, but it's
still not possible with todays CA policies.
[-- Attachment #2: Type: text/html, Size: 1695 bytes --]
next prev parent reply other threads:[~2013-04-25 10:52 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
2013-04-25 10:52 ` Mike Hearn [this message]
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='CANEZrP340hjkf8CyUnGBznRdGJWfxoAYmFOuTGbT8=pg2DNA+g@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