path: root/9b/b8272249a101d03983df51608a10d15d867f57

Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1WgFZ1-0000sc-IH
	for bitcoin-development@lists.sourceforge.net;
	Fri, 02 May 2014 15:39:51 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.219.50 as permitted sender)
	client-ip=209.85.219.50; envelope-from=mh.in.england@gmail.com;
	helo=mail-oa0-f50.google.com; 
Received: from mail-oa0-f50.google.com ([209.85.219.50])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WgFYz-0001Zy-Qw
	for bitcoin-development@lists.sourceforge.net;
	Fri, 02 May 2014 15:39:51 +0000
Received: by mail-oa0-f50.google.com with SMTP id i11so5405616oag.9
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 02 May 2014 08:39:44 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.60.132.236 with SMTP id ox12mr1066026oeb.81.1399045184158;
	Fri, 02 May 2014 08:39:44 -0700 (PDT)
Sender: mh.in.england@gmail.com
Received: by 10.76.96.180 with HTTP; Fri, 2 May 2014 08:39:44 -0700 (PDT)
Date: Fri, 2 May 2014 17:39:44 +0200
X-Google-Sender-Auth: qfRUfKvl19ENnwxgp8a5RcVJtxI
Message-ID: <CANEZrP15TKPcWnjdnfbRd9KxrS_5F=07gTL1DxyMo1os-sVOpA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=047d7b41cd283a01e504f86c97f2
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: 1WgFYz-0001Zy-Qw
Subject: [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 15:39:51 -0000

--047d7b41cd283a01e504f86c97f2
Content-Type: text/plain; charset=UTF-8

A bunch of different people either have implemented or are implementing
BIP70 at the moment. Here's a bunch of things I've been telling people in
response to questions. At some point I'll submit a pull req with this stuff
in but for now it's just an email.

*Error handling during signature checking*

I've had queries around the right behaviour here. BIP 70 is underspecified
and we should fix it IMO. If PKI checking fails you should just treat the
request as if it's unsigned. The reason is that there is no incentive for
an attacker to break the signature instead of just removing it entirely, so
an attacker would never trigger any error flows you put in. However,
someone who is signing their request with an unknown CA or using an
upgraded version of the protocol that isn't entirely backwards compatible
*could* trigger signature checking failure.

Therefore, in order to make introducing new (possibly community run) CA's
or new variations on signing possible, please treat any errors as if there
was no signature at all. This is not what browsers do,  but browsers have
an advantage - they were already given an identity and told to expect a
secure protocol when the user typed in the web address with an
https://prefix (or clicked a link). Unfortunately a Bitcoin wallet has
no context
like this.

One person asked me whether this makes the whole scheme pointless because a
MITM can just delete the signature. The answer is no - downgrade attacks
are always possible on systems that start out insecure. The solution is to
train users to expect the upgrade and refuse to go ahead if it's not there.
Training users to expect signed payment requests will be a big task similar
to the way the browser industry trained users to look for the padlock when
typing in credit card details, but it must be done.

Because wallets lack context there's no equivalent to HSTS for us either.
So in your GUI's try to train the user - when showing a signed payment
request, tell them to expect the recipient name to appear in future and
that they should not proceed if it doesn't. This gives us a kind of mental
HSTS.

*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.

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.

You should show the organisation data instead of the domain name if you
find it, for EV certs.

*pki=none*

Signing is optional in BIP 70 for good reasons. One implementor told me
they were considering rejecting unsigned payment requests. Do not do this!
A MITM can easily rewrite the bitcoin URI to look as if BIP70 isn't in use
at all.

Even though today most (all?) payment requests you'll encounter are signed,
it's important that signing is optional because in future we need
individual people to start generating payment requests too, and many of
them won't have any kind of memorisable digital identity. Plus other people
just won't want to do it. BIP70 is about lots of features, signing is only
one.

*S/MIME certs*

Email address certs look a bit different to SSL certs. You can get one for
free from here

    https://comodo.com/home/email-security/free-email-certificate.php

In these certs the display name can be found in the Subject Alternative
Name field with a type code of 1. Example code:


https://github.com/bitcoinj/bitcoinj/commit/feecc8f48641cd02cafc42150abba4e4841ea33d

You won't encounter many of these today except on Gavin's test site, but in
future people may wish to start creating and signing their own payment
requests for individual purposes using these certs (especially as they are
free). So please try to handle them correctly.

*Broadcast vs upload*

Please upload transactions and commit them to your wallet when the server
responds with 200 OK, but expect the merchant to broadcast them. Don't give
the user an option to pick - it's pointless as there's no obvious right
answer.

*Testing*

You can find a test site here:

http://bitcoincore.org/~gavin/createpaymentrequest.php

It's testnet only. For testing regular payment requests on the main
network, I use BitPay as they were the first seller-side implementation:

http://bitgivefoundation.org/donate-now/

*Memo contents*

Please put something useful here, ideally what is actually being sold but
failing that, the name of the merchant if you're a payment processor. Don't
be like BitPay and put large random numbers in the memo field but nothing
about what's actually purchased.

This is not particularly important today except for cosmetic reasons,
because wallets don't store the payment requests they saw to disk. But in
future they will and then a properly signed memo field + the transactions
used for payment give us a digital receipt. Receipts are useful for things
like filing expense reports, proving a purchase when returning an item to a
merchant, etc.

*Expiry times*

Don't be too aggressive with these. Although today it doesn't matter much,
some users may be trying to pay from multi-party accounts that require
multiple humans to coordinate to make a payment.

--047d7b41cd283a01e504f86c97f2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">A bunch of different people either have implemented or are=
 implementing BIP70 at the moment.=C2=A0Here&#39;s a bunch of things I&#39;=
ve been telling people in response to questions.=C2=A0At some point I&#39;l=
l submit a pull req with this stuff in but for now it&#39;s=C2=A0just an em=
ail.<div>
<div><br></div><div><b>Error handling during signature checking</b></div><d=
iv><b><br></b></div><div>I&#39;ve had queries around the right behaviour he=
re. BIP 70 is underspecified and we should fix it IMO. If PKI checking fail=
s you should just treat the request as if it&#39;s unsigned. The reason is =
that there is no incentive for an attacker to break the signature instead o=
f just removing it entirely, so an attacker would never trigger any error f=
lows you put in. However, someone who is signing their request with an unkn=
own CA or using an upgraded version of the protocol that isn&#39;t entirely=
 backwards compatible <i>could</i>=C2=A0trigger signature checking failure.=
</div>
</div><div><br></div><div>Therefore, in order to make introducing new (poss=
ibly community run) CA&#39;s or new variations on signing possible, please =
treat any errors as if there was no signature at all. This is not what brow=
sers do, =C2=A0but browsers have an advantage - they were already given an =
identity and told to expect a secure protocol when the user typed in the we=
b address with an https:// prefix (or clicked a link). Unfortunately a Bitc=
oin wallet has no context like this.</div>
<div><br></div><div>One person asked me whether this makes the whole scheme=
 pointless because a MITM can just delete the signature. The answer is no -=
 downgrade attacks are always possible on systems that start out insecure. =
The solution is to train users to expect the upgrade and refuse to go ahead=
 if it&#39;s not there. Training users to expect signed payment requests wi=
ll be a big task similar to the way the browser industry trained users to l=
ook for the padlock when typing in credit card details, but it must be done=
.</div>
<div><br></div><div>Because wallets lack context there&#39;s no equivalent =
to HSTS for us either. So in your GUI&#39;s try to train the user - when sh=
owing a signed payment request, tell them to expect the recipient name to a=
ppear in future and that they should not proceed if it doesn&#39;t. This gi=
ves us a kind of mental HSTS.</div>
<div><br></div><div><b>Extended validation certs</b></div><div><b><br></b><=
/div><div>When a business is accepting payment, showing the name of the bus=
iness is usually better than showing just the domain name, for a few reason=
s:</div>
<div><ol><li>Unless your domain name <i>is</i>=C2=A0your business name like=
 <a href=3D"http://blockchain.info">blockchain.info</a>, it looks better an=
d gives more info.<br><br></li><li>Domain names are more phishable than EV =
names, e.g. is the right name <a href=3D"http://bitpay.com">bitpay.com</a> =
or <a href=3D"http://bit-pay.com">bit-pay.com</a> or <a href=3D"http://bitp=
ay.co.uk">bitpay.co.uk</a>?<br>
<br></li><li>More important: Someone who hacks your web server or DNS provi=
der can silently get themselves a domain name SSL cert issued, probably wit=
hout you noticing. Certificate transparency will eventually fix that but it=
&#39;s years away from full deployment. It&#39;s much harder for a hacker t=
o get a bogus EV cert issued to them because there&#39;s a lot more checkin=
g involved.</li>
</ol><div>EV certs still have the domain name in the CN field, but they als=
o have the business name in the OU field.</div></div><div><br></div><div>In=
 theory we are supposed to have extra code to check that a certificate real=
ly was subject to extended validation before showing the contents of this f=
ield. In practice either bitcoinj nor Bitcoin Core actually do, they just a=
lways trust it. It&#39;d be nice to fix that in future.</div>
<div><br></div><div>You should show the organisation data instead of the do=
main name if you find it, for EV certs.</div><div><br></div><div><b>pki=3Dn=
one</b></div><div><b><br></b></div><div>Signing is optional in BIP 70 for g=
ood reasons. One implementor told me they were considering rejecting unsign=
ed payment requests. Do not do this! A MITM can easily rewrite the bitcoin =
URI to look as if BIP70 isn&#39;t in use at all.=C2=A0</div>
<div><br></div><div>Even though today most (all?) payment requests you&#39;=
ll encounter are signed, it&#39;s important that signing is optional becaus=
e in future we need individual people to start generating payment requests =
too, and many of them won&#39;t have any kind of memorisable digital identi=
ty. Plus other people just won&#39;t want to do it. BIP70 is about lots of =
features, signing is only one.</div>
<div><br></div><div><b>S/MIME certs</b></div><div><b><br></b></div><div>Ema=
il address certs look a bit different to SSL certs. You can get one for fre=
e from here</div><div><br></div><div>=C2=A0 =C2=A0 <a href=3D"https://comod=
o.com/home/email-security/free-email-certificate.php">https://comodo.com/ho=
me/email-security/free-email-certificate.php</a><br>
</div><div><br></div><div>In these certs the display name can be found in t=
he Subject Alternative Name field with a type code of 1. Example code:</div=
><div><br></div><div>=C2=A0 =C2=A0 <a href=3D"https://github.com/bitcoinj/b=
itcoinj/commit/feecc8f48641cd02cafc42150abba4e4841ea33d">https://github.com=
/bitcoinj/bitcoinj/commit/feecc8f48641cd02cafc42150abba4e4841ea33d</a></div=
>
<div><br></div><div>You won&#39;t encounter many of these today except on G=
avin&#39;s test site, but in future people may wish to start creating and s=
igning their own payment requests for individual purposes using these certs=
 (especially as they are free). So please try to handle them correctly.</di=
v>
<div><br></div><div><b>Broadcast vs upload</b></div><div><b><br></b></div><=
div>Please upload transactions and commit them to your wallet when the serv=
er responds with 200 OK, but expect the merchant to broadcast them. Don&#39=
;t give the user an option to pick - it&#39;s pointless as there&#39;s no o=
bvious right answer.</div>
<div><br></div><div><b>Testing</b></div><div><b><br></b></div><div>You can =
find a test site here:</div><div><br></div><div><a href=3D"http://bitcoinco=
re.org/~gavin/createpaymentrequest.php">http://bitcoincore.org/~gavin/creat=
epaymentrequest.php</a><br>
</div><div><br></div><div>It&#39;s testnet only. For testing regular paymen=
t requests on the main network, I use BitPay as they were the first seller-=
side implementation:</div><div><br></div><div><a href=3D"http://bitgivefoun=
dation.org/donate-now/">http://bitgivefoundation.org/donate-now/</a><br>
</div><div><br></div><div><b>Memo contents</b></div><div><b><br></b></div><=
div>Please put something useful here, ideally what is actually being sold b=
ut failing that, the name of the merchant if you&#39;re a payment processor=
. Don&#39;t be like BitPay and put large random numbers in the memo field b=
ut nothing about what&#39;s actually purchased.=C2=A0</div>
<div><br></div><div>This is not particularly important today except for cos=
metic reasons, because wallets don&#39;t store the payment requests they sa=
w to disk. But in future they will and then a properly signed memo field + =
the transactions used for payment give us a digital receipt. Receipts are u=
seful for things like filing expense reports, proving a purchase when retur=
ning an item to a merchant, etc.</div>
<div><br></div><div><b>Expiry times</b></div><div><b><br></b></div><div>Don=
&#39;t be too aggressive with these. Although today it doesn&#39;t matter m=
uch, some users may be trying to pay from multi-party accounts that require=
 multiple humans to coordinate to make a payment.</div>
<div><br></div><div><br></div><div><br></div><div><br></div><div><br></div>=
</div>

--047d7b41cd283a01e504f86c97f2--