From: Gregory Maxwell <gmaxwell@gmail.com>
To: Luke-Jr <luke@dashjr.org>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts
Date: Mon, 26 Nov 2012 19:16:07 -0500 [thread overview]
Message-ID: <CAAS2fgTacBqX7_YpGzUxtqt9okeCeeufsG8d0CYnwVXPF_bu7w@mail.gmail.com> (raw)
In-Reply-To: <201211262344.03385.luke@dashjr.org>
On Mon, Nov 26, 2012 at 6:44 PM, Luke-Jr <luke@dashjr.org> wrote:
> On Monday, November 26, 2012 11:32:46 PM Gregory Maxwell wrote:
>> Obviously the state of the world with browsers is not that good... but
>> in our own UAs we can do better and get closer to that.
>
> This effectively centralizes Bitcoin (at least in the eyes of many) and even
> if each competing client had their own list, you'd be back to the original
> "problem" of not being sure your CA is on all lists.
Thats the CA model generally. It _is_ a distributed-centralized model
in practice.
>> Would you find it acceptable if something supported a static whitelist
>> plus a OS provided list minus a user configured blacklist and the
>> ability for sophisticated users to disable the whitelist?
>
> How is this whitelist any different from the list of CAs included by default
> with every OS?
Because the list is not identical (and of course, couldn't be without
centralizing control of all OSes :P ) meaning that the software has to
be setup in a way where false-positive authentication failures are a
common thing (terrible for user security) or merchants have to waste a
bunch of time, probably unsuccessfully, figuring out what certs work
sufficiently 'everwhere' and likely end up handing over extortion
level fees to the most well established CAs that happen to be included
on the oldest and most obscure things.
Taking— say— the intersection of Chrome, Webkit, and Firefox's CA list
as of the first of the year every year and putting the result on a
whitelist would be a possible nothing-up-my-sleeve approach which is
not as limited as having some users subject to the WinXP cert list,
which IIRC is very limited (but not in a way that improves security!).
Jeff wrote:
> Self-signed certs are quite common, because it is easier, while being
> more secure than http://
Uhh. Really? Well, I agree with you that they should be (I
unsuccessfully lobbied browser vendors to make self-signed https on
http URLs JustWork and simply hide all user visible evidence of
security), but the really nasty warnings on those sites undermines the
security of the sites _and_ of other HTTPS sites because it conditions
users to click ignore-ignore-ignore. I don't think they are all that
common.
One thing which I think will be hard for us in this discussion is
being sensitive to the (quite justified!) concerns that the current CA
system is absolute rubbish, both terrible for security, usability, and
an unreasonable barrier to entry relative to the provided security—
without allowing the discussion to be usurped by everyone's pet
replacement, which there are a great many of with varying feasibility
and security.
Perhaps we should agree to talk about everything _except_ that first?
next prev parent reply other threads:[~2012-11-27 0:16 UTC|newest]
Thread overview: 87+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-26 22:37 [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts Gavin Andresen
2012-11-26 23:02 ` Mike Hearn
2012-11-26 23:13 ` Luke-Jr
2012-11-26 23:16 ` Mike Hearn
2012-11-26 23:19 ` Luke-Jr
2012-11-26 23:27 ` Mike Hearn
2012-11-26 23:32 ` Gregory Maxwell
2012-11-26 23:44 ` Luke-Jr
2012-11-27 0:16 ` Gregory Maxwell [this message]
2012-11-27 0:26 ` Mike Hearn
2012-11-27 0:45 ` Rick Wesson
2012-11-27 1:09 ` Gavin
2012-11-27 8:44 ` Mike Hearn
2012-11-27 0:44 ` Luke-Jr
2012-11-26 23:38 ` Rick Wesson
2012-11-26 23:52 ` Jeff Garzik
2012-11-27 0:02 ` Rick Wesson
2012-11-27 0:31 ` Luke-Jr
2012-11-27 0:37 ` Rick Wesson
2012-11-27 2:16 ` Walter Stanish
2012-11-27 2:47 ` Gregory Maxwell
2012-11-27 3:16 ` Walter Stanish
2012-11-27 3:29 ` Rick Wesson
2012-11-27 3:31 ` Walter Stanish
2012-11-27 3:54 ` Rick Wesson
2012-11-27 4:17 ` Walter Stanish
2012-11-27 8:43 ` Michael Gronager
2012-11-27 10:23 ` Mike Hearn
2012-11-27 10:42 ` Michael Gronager
2012-11-27 11:36 ` Pieter Wuille
2012-11-27 11:46 ` Michael Gronager
2012-11-27 12:03 ` Mike Hearn
2012-11-27 12:39 ` Michael Gronager
2012-11-27 14:05 ` Gavin Andresen
2012-11-27 14:26 ` Gavin Andresen
2012-11-28 13:55 ` Walter Stanish
2012-11-27 17:03 ` Andy Parkins
2012-11-27 17:14 ` Mike Hearn
2012-11-27 17:26 ` Andy Parkins
2012-11-27 18:16 ` Mike Hearn
2012-11-27 21:39 ` Gavin Andresen
2012-11-28 10:43 ` Mike Hearn
2012-11-28 12:57 ` Peter Todd
2012-11-28 14:09 ` Gavin Andresen
2012-11-28 8:33 ` Peter Todd
2012-11-28 23:36 ` Roy Badami
2012-11-29 0:30 ` Watson Ladd
2012-11-29 8:16 ` slush
2012-11-29 16:11 ` Gavin Andresen
2012-11-29 17:07 ` Roy Badami
2012-11-29 17:30 ` Gavin Andresen
2012-11-29 17:31 ` Mike Hearn
2012-11-29 18:53 ` Roy Badami
2012-12-01 19:25 ` Gavin Andresen
2012-12-03 19:35 ` Mike Koss
2012-12-03 20:59 ` Gavin Andresen
2012-12-03 21:28 ` Mike Hearn
2012-12-03 22:26 ` Roy Badami
2012-12-03 22:34 ` Jeff Garzik
2012-12-03 22:48 ` Roy Badami
2012-12-16 21:15 ` Melvin Carvalho
2012-12-17 2:18 ` Jeff Garzik
2012-12-17 8:24 ` Melvin Carvalho
2012-12-17 9:19 ` Mike Hearn
2012-12-17 9:31 ` Gary Rowe
2012-12-17 11:23 ` Melvin Carvalho
2012-12-17 17:57 ` Gavin Andresen
2012-12-20 16:53 ` Stephen Pair
2012-12-20 17:43 ` Mike Hearn
2012-12-20 19:32 ` Stephen Pair
2012-12-21 17:05 ` Stephen Pair
2012-12-24 0:38 ` Elden Tyrell
2012-12-04 17:06 ` Mike Hearn
2012-12-05 19:34 ` Gavin Andresen
2012-12-06 6:31 ` Andreas Petersson
2012-12-06 8:53 ` Mike Hearn
2012-12-06 16:56 ` Gavin Andresen
2012-12-06 17:55 ` Mike Hearn
2012-12-06 19:13 ` Gavin Andresen
2012-12-07 10:45 ` Mike Hearn
2012-12-07 11:01 ` Mike Hearn
2012-12-07 16:19 ` Gavin Andresen
2012-12-07 16:27 ` Mike Hearn
2012-12-06 18:13 ` Alan Reiner
[not found] ` <CALf2ePx5jS@mail.gmail.com>
2014-09-17 19:28 ` Vezalke
2012-12-03 21:42 ` Gregory Maxwell
2012-12-23 2:33 ` Mark Friedenbach
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=CAAS2fgTacBqX7_YpGzUxtqt9okeCeeufsG8d0CYnwVXPF_bu7w@mail.gmail.com \
--to=gmaxwell@gmail.com \
--cc=bitcoin-development@lists.sourceforge.net \
--cc=luke@dashjr.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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