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
115
116
117
118
119
120
121
122
123
124
125
126
127
|
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 <mh.in.england@gmail.com>) id 1WK3sM-0002kK-KV
for bitcoin-development@lists.sourceforge.net;
Sun, 02 Mar 2014 10:44:06 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.179 as permitted sender)
client-ip=209.85.214.179; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f179.google.com;
Received: from mail-ob0-f179.google.com ([209.85.214.179])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WK3sL-000440-T4
for bitcoin-development@lists.sourceforge.net;
Sun, 02 Mar 2014 10:44:06 +0000
Received: by mail-ob0-f179.google.com with SMTP id va2so956860obc.24
for <bitcoin-development@lists.sourceforge.net>;
Sun, 02 Mar 2014 02:44:00 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.60.246.10 with SMTP id xs10mr11535962oec.18.1393757040590;
Sun, 02 Mar 2014 02:44:00 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.231 with HTTP; Sun, 2 Mar 2014 02:44:00 -0800 (PST)
In-Reply-To: <op.xb3btqp7yldrnw@laptop-air>
References: <CANEZrP1eABw_x8o-Z9ac23e-dVvUWfZJ-hKfAak=-NicPhUv9g@mail.gmail.com>
<op.xb3btqp7yldrnw@laptop-air>
Date: Sun, 2 Mar 2014 11:44:00 +0100
X-Google-Sender-Auth: 5NAjBrJIgbX7NJqaWdwb-kQ_BAY
Message-ID: <CANEZrP0bkyO=L_9RAbgGCXhWSn+Tc_F12tMxqVz9d0Vd=kaU8w@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jeremy Spilman <jeremy@taplink.co>
Content-Type: multipart/alternative; boundary=001a1136989a4ec84904f39d59f1
X-Spam-Score: -0.5 (/)
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
1.0 HTML_MESSAGE BODY: HTML included in message
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
X-Headers-End: 1WK3sL-000440-T4
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP70 extension to allow for identity
delegation
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: Sun, 02 Mar 2014 10:44:06 -0000
--001a1136989a4ec84904f39d59f1
Content-Type: text/plain; charset=UTF-8
>
> Perhaps the UI just isn't expressive enough currently to expose this
> situation in any way, let alone reliably alert the user to the issue,
> because there's no way for the payment processor to get authenticated
> fields other than memo into the UI.
>
I think for now as long as payment processors include the merchant name in
the memo, that's good - as long as hardware devices or second factor
wallets display the memo as well! Trezor has a small screen, I don't know
how feasible displaying the whole memo is there though - hence an interest
in something better. For now we can probably muddle through.
> A poor solution: If the UI included some sort of certificate viewer, even
> just tied to the OS certificate viewer, and made the cert available for
> inspection, at least the merchant would have a chance to put some fields in
> there which a very advanced user might actually find.
>
Not really interested in solutions that only help very advanced users.
Besides, my understanding is that most PKI CA's will not sign certs that
include arbitrary data they don't understand for I guess the obvious
security reasons (generally signing things you don't understand is a bad
idea). But I've never actually tried it.
We don't want anyone to have to go back to their CA anyway, especially not
with special requests.
--001a1136989a4ec84904f39d59f1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex"><div>Perhaps the UI just isn't expressive en=
ough currently to expose this situation in any way, let alone reliably aler=
t the user to the issue, because there's no way for the payment process=
or to get authenticated fields other than memo into the UI.<br>
</div></blockquote><div><br></div><div>I think for now as long as payment p=
rocessors include the merchant name in the memo, that's good - as long =
as hardware devices or second factor wallets display the memo as well! Trez=
or has a small screen, I don't know how feasible displaying the whole m=
emo is there though - hence an interest in something better. For now we can=
probably muddle through.</div>
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div></div><div>A poor solu=
tion: If the UI included some sort of certificate viewer, even just tied to=
the OS certificate viewer, and made the cert available for inspection, at =
least the merchant would have a chance to put some fields in there which a =
very advanced user might actually find.</div>
</blockquote><div><br></div><div>Not really interested in solutions that on=
ly help very advanced users. Besides, my understanding is that most PKI CA&=
#39;s will not sign certs that include arbitrary data they don't unders=
tand for I guess the obvious security reasons (generally signing things you=
don't understand is a bad idea). But I've never actually tried it.=
</div>
<div><br></div><div>We don't want anyone to have to go back to their CA=
anyway, especially not with special requests.</div></div></div></div>
--001a1136989a4ec84904f39d59f1--
|
