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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1TdGmi-0000bV-BR
for bitcoin-development@lists.sourceforge.net;
Tue, 27 Nov 2012 08:44:52 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.175 as permitted sender)
client-ip=209.85.214.175; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f175.google.com;
Received: from mail-ob0-f175.google.com ([209.85.214.175])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1TdGmc-0008Lk-VA
for bitcoin-development@lists.sourceforge.net;
Tue, 27 Nov 2012 08:44:52 +0000
Received: by mail-ob0-f175.google.com with SMTP id vb8so11206538obc.34
for <bitcoin-development@lists.sourceforge.net>;
Tue, 27 Nov 2012 00:44:41 -0800 (PST)
MIME-Version: 1.0
Received: by 10.60.31.51 with SMTP id x19mr11576841oeh.25.1354005881601; Tue,
27 Nov 2012 00:44:41 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.128.139 with HTTP; Tue, 27 Nov 2012 00:44:41 -0800 (PST)
In-Reply-To: <CAJ1JLts=WW3r-eV50513uB=a3XJvPcgjPTwG3OhQ3XnPtM3BNQ@mail.gmail.com>
References: <CABsx9T0PsGLEAWRCjEDDFWQrb+DnJWQZ7mFLaZewAEX6vD1eHw@mail.gmail.com>
<201211262319.37533.luke@dashjr.org>
<CAAS2fgS3f1RKzPnni4LXgXfSUrxSrB3+vhdmbsVz2Rs5pScL=w@mail.gmail.com>
<201211262344.03385.luke@dashjr.org>
<CAAS2fgTacBqX7_YpGzUxtqt9okeCeeufsG8d0CYnwVXPF_bu7w@mail.gmail.com>
<CANEZrP0fhM=N=LsYa=za8MobiJYG9Fbpv+WniL8td6pRpr6jgQ@mail.gmail.com>
<CAJ1JLts=WW3r-eV50513uB=a3XJvPcgjPTwG3OhQ3XnPtM3BNQ@mail.gmail.com>
Date: Tue, 27 Nov 2012 09:44:41 +0100
X-Google-Sender-Auth: 2tuUAOcI4-MH6_4n3iLB_0L8PHY
Message-ID: <CANEZrP0aimUU5znnG7+3jdhVif+dd_R9P+8fcAh9C5cyyZjhTA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Rick Wesson <rick@support-intelligence.com>
Content-Type: text/plain; charset=UTF-8
X-Spam-Score: -1.3 (-)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
0.2 AWL AWL: From: address is in the auto white-list
X-Headers-End: 1TdGmc-0008Lk-VA
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Payment Protocol Proposal:
Invoices/Payments/Receipts
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: Tue, 27 Nov 2012 08:44:52 -0000
Luke-Jr - common subset of what operating systems ship is fine for me
as long as people do due diligence around mobile OS' here. It seems
easier to me to just grab a list from a popular browser, on the
grounds that SSL is mostly used by them so nobody is going to buy an
SSL cert rejected by IE/Firefox/Chrome/etc. But intersecting OS lists
is effectively the same.
For my own clients I'd just ship my own copy of the canonical CA certs
regardless, because integrating with each operating systems
proprietary crypto APIs is a lot of work vs just loading a pem file
into OpenSSL. If there are a lot of people who want to use the OS cert
management UIs then I guess that can be a point wallet clients compete
on.
> Removing that and adding a opaque string called domain name, or
> identityName would be sufficient to move the conversation forward
> without the x.509 baggage.
But it would result in implementations that do not meet the requirements.
Yes, X.509 has problems. It's in the proposal because we can get the
effect we want (verifiable domain names in the UI) in about 50 lines
of code, today, with the id-verified keys people actually have already
bought.
As Gavin says, we can add optional fields later to extend the protocol
in a backwards compatible way.
|
