path: root/1b/334ce164e1abdfaef8e852de28ebc9381bb87e

Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <mh.in.england@gmail.com>) id 1WJLu3-0004sE-V8
	for bitcoin-development@lists.sourceforge.net;
	Fri, 28 Feb 2014 11:46:56 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.214.174 as permitted sender)
	client-ip=209.85.214.174; envelope-from=mh.in.england@gmail.com;
	helo=mail-ob0-f174.google.com; 
Received: from mail-ob0-f174.google.com ([209.85.214.174])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1WJLu2-0002iY-GE
	for bitcoin-development@lists.sourceforge.net;
	Fri, 28 Feb 2014 11:46:55 +0000
Received: by mail-ob0-f174.google.com with SMTP id wo20so1487076obc.5
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 28 Feb 2014 03:46:49 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.60.84.199 with SMTP id b7mr2120447oez.55.1393588009112; Fri,
	28 Feb 2014 03:46:49 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.71.231 with HTTP; Fri, 28 Feb 2014 03:46:49 -0800 (PST)
Date: Fri, 28 Feb 2014 12:46:49 +0100
X-Google-Sender-Auth: 9h9aA79EWeLVyybWPYK9bZH-9Yw
Message-ID: <CANEZrP1eABw_x8o-Z9ac23e-dVvUWfZJ-hKfAak=-NicPhUv9g@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Content-Type: multipart/alternative; boundary=089e0102dc823f1b5104f375fe65
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: 1WJLu2-0002iY-GE
Subject: [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: Fri, 28 Feb 2014 11:46:56 -0000

--089e0102dc823f1b5104f375fe65
Content-Type: text/plain; charset=UTF-8

Now we're starting to see the first companies deploy BIP70, we're
encountering a need for identity delegation. This need was long foreseen by
the way: it's not in BIP70 because, well, we had to draw the line for v1
somewhere, and this is an issue that mostly affects payment processors. But
I figured I'd start a thread anyway because people keep asking me about it
:)

*Objective*

Identity delegation means that a payment request can be signed by someone
who is not holding the certified private key. The most obvious use case for
this is payment processors like BitPay and Coinbase who currently have to
sign payment requests as themselves. Other use cases might involve
untrusted sales agents who want to be able to accept payment as their
employer, but cannot be trusted with a long-term valuable secret, e.g.
because they take their phone into areas with high crime rates.

The lack of this is ok for v1 but not great, because:

1) It requires the name of the *actual* recipient to be put in the memo
field, otherwise you don't have the nice receipt-like properties. The memo
field is just plain text though, it doesn't have any exploitable structure.

2) It gives a confusing UI, the user thinks they're paying e.g. Overstock
but their wallet UI tells them they're paying Coinbase

3) Whilst these payment processors currently verify merchants so the
security risk is low, in future a lighter-weight model or competing sites
that allow open signups would give a weak security situation:  a hacker who
compromised your computer could sign up for some popular payment processor
under a false identity (or no identity), and wait until you use your hacked
computer to make a payment to someone else using the same payment
processor. They could then do an identity swap of the real payment request
for one of their own, and your Trezor would still look the same. Avoiding
this is a major motivation for the entire system!

Also it just looks more professional if the name you see in the wallet UI
is correct.

*Proposed implementation*

We can fix this with a simple extension:

enum KeyType {
  SECP256K1 = 1
}

message ExtensionCert {
  required bytes signature = 1;
  required bytes public_key = 2;
  required KeyType key_type = 3;
  required uint32 expiry_time = 4;
  optional string memo = 5;
}

// modification
message X509Certificates {
  repeated bytes certificate = 1;
  repeated ExtensionCert extended_certs = 2;
}

message PaymentRequest {
  // new field
  optional bytes extended_signature = 6;
}

This allow us to define a so-called *extended certificate*, which is
conceptually the same as an X.509 certificate except simpler and Bitcoin
specific. To create one, you just format a ExtensionCert message with an
ECDSA public key from the payment processor (PP), set signature to an empty
array and then sign it using your SSL private key. Obviously the resulting
(most likely RSA) signature then goes into the signature field of the
ExtensionCert. The memo field could optionally indicate the purpose of this
cert, like "Delegation to BitPay" but I don't think it'd ever appear in the
UI, rather, it should be there for debugging purposes.

The new ExtensionCert can then be provided back to the PP who adds it to
the X509Certificates message. In the PaymentRequest, there are now
*two* signature
fields (this is for backwards compatibility). Because of how the mechanism
is designed they should not interfere with each other - old implementations
that don't understand the new extended_signature field will drop it during
reserialization to set signature to the empty array, and thus signature
should not cover that field. On the other hand, extended_signature would
cover signature. Thus, for full backwards compatibility, you would:

1) Sign the payment request using the PP's SSL cert, i.e. sign as
coinbase.com

2) Then sign again using the PP's delegated ECDSA key, i.e. sign as the
merchant

The finished protobuf would show up in old clients as signed by
coinbase.comand by new clients as signed by
overstock.com even though Overstock did not provide their SSL key to
coinbase.

If you have *only* an ExtensionCert and not any X.509 cert of your own,
then you cannot of course make backwards compatible signatures in this way,
and in that case you would miss out the signature field and set the
pki_type to a new value:  "x509+sha256+excert". Old wallets would see that
they don't understand this pki_type and treat the request as unverified.

For maximum security the merchant may choose to set very short expiry times
(like, a day) and then have a cron job that uploads a new ExtensionCert at
the end of each expiry period. This means in the case of PP compromise, the
system reseals very fast.

*Alternatives considered*

We could always use a new pki_type and not bother with the two signature
fields. However, this means old wallets will show payment requests as
untrusted during the transition period. Some signing is still better than
none, security-wise.

We could attempt to fix the above by introducing a use of User-Agent field
to the case where a payment request is fetched via HTTP, so the server can
customise the PaymentRequest according to the capabilities of the client.
However, sometimes payment requests are not fetched via HTTP, for example,
they may be attached to an email, sent via an IM network or sent over a
Bluetooth socket. Nonetheless this may be a useful thing to consider for
future cases where the protocol may not be extended in a backwards
compatible manner.

We could create the extension cert as an X.509 cert, rather than a custom
type. However most CA's set path length constraints on their intermediate
certs that forbid this kind of extension (I forgot why, possibly some kind
of anti-DoS mitigation). Also re-using X.509 for the extension cert would
open up the risk of it being accepted by a bogus SSL stack that didn't
check the key usage constraints extension, and that would allow for SSL
delegation as well. It seems safer to just use a different format that
definitely won't be accepted.



Feedback welcome.

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

<div dir=3D"ltr">Now we&#39;re starting to see the first companies deploy B=
IP70, we&#39;re encountering a need for identity delegation. This need was =
long foreseen by the way: it&#39;s not in BIP70 because, well, we had to dr=
aw the line for v1 somewhere, and this is an issue that mostly affects paym=
ent processors. But I figured I&#39;d start a thread anyway because people =
keep asking me about it :)<div>
<br></div><div><b><u>Objective</u></b><br><div><br></div><div>Identity dele=
gation means that a payment request can be signed by someone who is not hol=
ding the certified private key. The most obvious use case for this is payme=
nt processors like BitPay and Coinbase who currently have to sign payment r=
equests as themselves. Other use cases might involve untrusted sales agents=
 who want to be able to accept payment as their employer, but cannot be tru=
sted with a long-term valuable secret, e.g. because they take their phone i=
nto areas with high crime rates.=C2=A0</div>
<div><br></div><div>The lack of this is ok for v1 but not great, because:</=
div><div><br></div><div>1) It requires the name of the *actual* recipient t=
o be put in the memo field, otherwise you don&#39;t have the nice receipt-l=
ike properties. The memo field is just plain text though, it doesn&#39;t ha=
ve any exploitable structure.</div>
<div><br></div><div>2) It gives a confusing UI, the user thinks they&#39;re=
 paying e.g. Overstock but their wallet UI tells them they&#39;re paying Co=
inbase</div><div><br></div><div>3) Whilst these payment processors currentl=
y verify merchants so the security risk is low, in future a lighter-weight =
model or competing sites that allow open signups would give a weak security=
 situation: =C2=A0a hacker who compromised your computer could sign up for =
some popular payment processor under a false identity (or no identity), and=
 wait until you use your hacked computer to make a payment to someone else =
using the same payment processor. They could then do an identity swap of th=
e real payment request for one of their own, and your Trezor would still lo=
ok the same. Avoiding this is a major motivation for the entire system!</di=
v>
<div><br></div><div>Also it just looks more professional if the name you se=
e in the wallet UI is correct.</div><div><br></div><div><b><u>Proposed impl=
ementation</u></b></div><div><br></div><div>We can fix this with a simple e=
xtension:</div>
<div><br></div><div><font face=3D"courier new, monospace">enum KeyType {</f=
ont></div><div><font face=3D"courier new, monospace">=C2=A0 SECP256K1 =3D 1=
</font></div><div><font face=3D"courier new, monospace">}</font></div><div>=
<font face=3D"courier new, monospace"><br>
</font></div><div><font face=3D"courier new, monospace">message ExtensionCe=
rt {</font></div><div><font face=3D"courier new, monospace">=C2=A0 required=
 bytes signature =3D 1;</font></div><div><font face=3D"courier new, monospa=
ce">=C2=A0 required bytes public_key =3D 2;</font></div>
<div><font face=3D"courier new, monospace">=C2=A0 required KeyType key_type=
 =3D 3;</font></div><div><font face=3D"courier new, monospace">=C2=A0 requi=
red uint32 expiry_time =3D 4;</font></div><div><font face=3D"courier new, m=
onospace">=C2=A0 optional string memo =3D 5;</font></div>
<div><font face=3D"courier new, monospace">}</font></div><div><font face=3D=
"courier new, monospace"><br></font></div><div><font face=3D"courier new, m=
onospace">// modification</font></div><div><font face=3D"courier new, monos=
pace">message X509Certificates {</font></div>
<div><font face=3D"courier new, monospace">=C2=A0 repeated bytes certificat=
e =3D 1;</font></div><div><font face=3D"courier new, monospace">=C2=A0 repe=
ated ExtensionCert extended_certs =3D 2;</font></div><div><font face=3D"cou=
rier new, monospace">}</font></div>
<div><font face=3D"courier new, monospace"><br></font></div><div><font face=
=3D"courier new, monospace">message PaymentRequest {</font></div><div><font=
 face=3D"courier new, monospace">=C2=A0 // new field</font></div><div><font=
 face=3D"courier new, monospace">=C2=A0 optional bytes extended_signature =
=3D 6;</font></div>
<div><font face=3D"courier new, monospace">}</font></div><div><br></div><di=
v>This allow us to define a so-called <i>extended certificate</i>, which is=
 conceptually the same as an X.509 certificate except simpler and Bitcoin s=
pecific. To create one, you just format a ExtensionCert message with an ECD=
SA public key from the payment processor (PP), set signature to an empty ar=
ray and then sign it using your SSL private key. Obviously the resulting (m=
ost likely RSA) signature then goes into the signature field of the Extensi=
onCert. The memo field could optionally indicate the purpose of this cert, =
like &quot;Delegation to BitPay&quot; but I don&#39;t think it&#39;d ever a=
ppear in the UI, rather, it should be there for debugging purposes.</div>
<div><br></div><div>The new ExtensionCert can then be provided back to the =
PP who adds it to the X509Certificates message. In the PaymentRequest, ther=
e are now <i>two</i>=C2=A0signature fields (this is for backwards compatibi=
lity). Because of how the mechanism is designed they should not interfere w=
ith each other - old implementations that don&#39;t understand the new exte=
nded_signature field will drop it during reserialization to set signature t=
o the empty array, and thus signature should not cover that field. On the o=
ther hand, extended_signature would cover signature. Thus, for full backwar=
ds compatibility, you would:</div>
<div><br></div><div>1) Sign the payment request using the PP&#39;s SSL cert=
, i.e. sign as <a href=3D"http://coinbase.com">coinbase.com</a></div><div><=
br></div><div>2) Then sign again using the PP&#39;s delegated ECDSA key, i.=
e. sign as the merchant</div>
<div><br></div><div>The finished protobuf would show up in old clients as s=
igned by <a href=3D"http://coinbase.com">coinbase.com</a> and by new client=
s as signed by <a href=3D"http://overstock.com">overstock.com</a> even thou=
gh Overstock did not provide their SSL key to coinbase.</div>
<div><br></div><div>If you have <i>only</i>=C2=A0an ExtensionCert and not a=
ny X.509 cert of your own, then you cannot of course make backwards compati=
ble signatures in this way, and in that case you would miss out the signatu=
re field and set the pki_type to a new value: =C2=A0&quot;x509+sha256+excer=
t&quot;. Old wallets would see that they don&#39;t understand this pki_type=
 and treat the request as unverified.</div>
<div><br></div><div>For maximum security the merchant may choose to set ver=
y short expiry times (like, a day) and then have a cron job that uploads a =
new ExtensionCert at the end of each expiry period. This means in the case =
of PP compromise, the system reseals very fast.</div>
<div><br></div><div><b><u>Alternatives considered</u></b></div></div><div><=
b><u><br></u></b></div><div>We could always use a new pki_type and not both=
er with the two signature fields. However, this means old wallets will show=
 payment requests as untrusted during the transition period. Some signing i=
s still better than none, security-wise.</div>
<div><br></div><div>We could attempt to fix the above by introducing a use =
of User-Agent field to the case where a payment request is fetched via HTTP=
, so the server can customise the PaymentRequest according to the capabilit=
ies of the client. However, sometimes payment requests are not fetched via =
HTTP, for example, they may be attached to an email, sent via an IM network=
 or sent over a Bluetooth socket. Nonetheless this may be a useful thing to=
 consider for future cases where the protocol may not be extended in a back=
wards compatible manner.</div>
<div><br></div><div>We could create the extension cert as an X.509 cert, ra=
ther than a custom type. However most CA&#39;s set path length constraints =
on their intermediate certs that forbid this kind of extension (I forgot wh=
y, possibly some kind of anti-DoS mitigation). Also re-using X.509 for the =
extension cert would open up the risk of it being accepted by a bogus SSL s=
tack that didn&#39;t check the key usage constraints extension, and that wo=
uld allow for SSL delegation as well. It seems safer to just use a differen=
t format that definitely won&#39;t be accepted.</div>
<div><br></div><div><br></div><div><br></div><div>Feedback welcome.</div></=
div>

--089e0102dc823f1b5104f375fe65--