1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <roy@gnomon.org.uk>) id 1WgKHP-0007kn-K7
for bitcoin-development@lists.sourceforge.net;
Fri, 02 May 2014 20:41:59 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gnomon.org.uk
designates 93.93.131.22 as permitted sender)
client-ip=93.93.131.22; envelope-from=roy@gnomon.org.uk;
helo=darla.gnomon.org.uk;
Received: from darla.gnomon.org.uk ([93.93.131.22])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1WgKHN-0002Rf-Lt
for bitcoin-development@lists.sourceforge.net;
Fri, 02 May 2014 20:41:59 +0000
Received: from darla.gnomon.org.uk (localhost.gnomon.org.uk [127.0.0.1])
by darla.gnomon.org.uk (8.14.3/8.14.3) with ESMTP id s42KflOU088511
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
Fri, 2 May 2014 21:41:52 +0100 (BST)
(envelope-from roy@darla.gnomon.org.uk)
Received: (from roy@localhost)
by darla.gnomon.org.uk (8.14.3/8.14.1/Submit) id s42KflPR088510;
Fri, 2 May 2014 21:41:47 +0100 (BST) (envelope-from roy)
Date: Fri, 2 May 2014 21:41:47 +0100
From: Roy Badami <roy@gnomon.org.uk>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20140502204146.GD62950@giles.gnomon.org.uk>
References: <CANEZrP15TKPcWnjdnfbRd9KxrS_5F=07gTL1DxyMo1os-sVOpA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CANEZrP15TKPcWnjdnfbRd9KxrS_5F=07gTL1DxyMo1os-sVOpA@mail.gmail.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
X-Spam-Score: -2.2 (--)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
-0.7 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1WgKHN-0002Rf-Lt
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70 implementation guidance
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 02 May 2014 20:41:59 -0000
> *Extended validation certs*
>
> When a business is accepting payment, showing the name of the business is
> usually better than showing just the domain name, for a few reasons:
>
> 1. Unless your domain name *is* your business name like blockchain.info,
> it looks better and gives more info.
>
> 2. Domain names are more phishable than EV names, e.g. is the right name
> bitpay.com or bit-pay.com or bitpay.co.uk?
>
> 3. More important: Someone who hacks your web server or DNS provider can
> silently get themselves a domain name SSL cert issued, probably without you
> noticing. Certificate transparency will eventually fix that but it's years
> away from full deployment. It's much harder for a hacker to get a bogus EV
> cert issued to them because there's a lot more checking involved.
>
> EV certs still have the domain name in the CN field, but they also have the
> business name in the OU field.
Well, many certs have something in the O field. That has nothing to
do with EV - EV just mandates a particular set of validation
requirements.
>
> In theory we are supposed to have extra code to check that a certificate
> really was subject to extended validation before showing the contents of
> this field. In practice either bitcoinj nor Bitcoin Core actually do, they
> just always trust it. It'd be nice to fix that in future.
I agree that blindly showing the O field may not be ideal - there
*may* conceivably be some CAs that include it without validation on
their cheap certs (although most cheap certs simply don't include it).
But it's not clear that EV or not is the right criterion here - there
are certainly non-EV certs out there that are organisation validated.
> You should show the organisation data instead of the domain name if you
> find it, for EV certs.
I have really mixed feelings about giving this privileged treatment
exclusively to EV certs, for the simple reason that the rules around
EV certs are iniquitous and some businesses are excluded.
e.g. in the UK sole traders (that is, unincorporated businesses) can't
get EV certs because the UK doesn't maintain a trade register of such
businesses and therefore such businesses are incapable of satisfying
the EV rules.
That said, EV certs are here, now, and (sadly) supporting them is
better than doing nothing...
roy
|
