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
|
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 <jeremy@taplink.co>) id 1WJegx-0005OZ-N5
for bitcoin-development@lists.sourceforge.net;
Sat, 01 Mar 2014 07:50:39 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of taplink.co
designates 50.117.27.232 as permitted sender)
client-ip=50.117.27.232; envelope-from=jeremy@taplink.co;
helo=mail.taplink.co;
Received: from mail.taplink.co ([50.117.27.232])
by sog-mx-1.v43.ch3.sourceforge.com with smtp (Exim 4.76)
id 1WJegw-0000wP-Vv for bitcoin-development@lists.sourceforge.net;
Sat, 01 Mar 2014 07:50:39 +0000
Received: from laptop-air ([192.168.168.135]) by mail.taplink.co
; Fri, 28 Feb 2014 23:50:48 -0800
Content-Type: multipart/alternative; boundary=----------HuvgV2oycVxhn4Te0WCBxM
To: Wladimir <laanwj@gmail.com>
References: <op.xb05iptvyldrnw@laptop-air>
<CA+s+GJBD-L8Lz+dsEgL+_xzJbrqjC7z_9Z45ow=xoccxwEdssQ@mail.gmail.com>
Date: Fri, 28 Feb 2014 23:50:32 -0800
MIME-Version: 1.0
From: "Jeremy Spilman" <jeremy@taplink.co>
Organization: TapLink
Message-ID: <op.xb09eip8yldrnw@laptop-air>
In-Reply-To: <CA+s+GJBD-L8Lz+dsEgL+_xzJbrqjC7z_9Z45ow=xoccxwEdssQ@mail.gmail.com>
User-Agent: Opera Mail/1.0 (Win32)
X-Spam-Score: -0.6 (/)
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_PASS SPF: sender matches SPF record
-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain 1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
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: 1WJegw-0000wP-Vv
Cc: "bitcoin-development@lists.sourceforge.net"
<bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Positive and negative feedback on
certificate validation errors
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: Sat, 01 Mar 2014 07:50:39 -0000
------------HuvgV2oycVxhn4Te0WCBxM
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
On Fri, 28 Feb 2014 23:26:57 -0800, Wladimir <laanwj@gmail.com> wrote:
> Such a thing would be interesting for a future BIP standard. I see one
> problem here: for an unsigned payment request there isn't really an
> "origin". >Browser URI handlers don't send the referrer either.
Yeah, good point. If you have a cert, we have the CN from the cert, which
becomes the string displayed as 'Pay To' and alternatively 'Merchant'.
But if there's no cert then all you have is memo.
So the best way to differentiate signed requests is by prominently
displaying that Merchant string. Really the green part should just be the
'Pay To' line, the rest is content. If it showed a BLANK 'Pay To' that
would make the lack of certificate highly apparent.
------------HuvgV2oycVxhn4Te0WCBxM
Content-Type: multipart/related; boundary=----------HuvgV2oycVxhn4ru9Zz9SZ
------------HuvgV2oycVxhn4ru9Zz9SZ
Content-Type: text/html; charset=iso-8859-15
Content-ID: <op.1393660232250.ad40d27d5d6b4d8d@192.168.168.135>
Content-Transfer-Encoding: Quoted-Printable
<!DOCTYPE html><html><head>
<style type=3D"text/css">body { font-family:'Times New Roman'; font-size=
:13px}</style>
</head>
<body>On Fri, 28 Feb 2014 23:26:57 -0800, Wladimir <laanwj@gmail.com&=
gt; wrote:<br><br><blockquote style=3D"margin: 0 0 0.80ex; border-left: =
#0000FF 2px solid; padding-left: 1ex">Such a thing would be interesting =
for a future BIP standard. I see one problem here: for an unsigned payme=
nt request there isn't really an "origin". Browser URI handlers don't se=
nd the referrer either.</blockquote><br><div>Yeah, good point. If you ha=
ve a cert, we have the CN from the cert, which becomes the string displa=
yed as 'Pay To' and alternatively 'Merchant'.</div><div><br></div><div>B=
ut if there's no cert then all you have is memo.</div><div><br></div><di=
v>So the best way to differentiate signed requests is by prominently dis=
playing that Merchant string. Really the green part should just be the '=
Pay To' line, the rest is content. If it showed a BLANK 'Pay To' that wo=
uld make the lack of certificate highly apparent. </div><div><br></=
div><div><br></div></body></html>
------------HuvgV2oycVxhn4ru9Zz9SZ--
------------HuvgV2oycVxhn4Te0WCBxM--
|
