From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) id 1WJqkA-0006GU-Bk for bitcoin-development@lists.sourceforge.net; Sat, 01 Mar 2014 20:42:46 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.160.176 as permitted sender) client-ip=209.85.160.176; envelope-from=kgreenek@gmail.com; helo=mail-yk0-f176.google.com; Received: from mail-yk0-f176.google.com ([209.85.160.176]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1WJqk8-0005rT-NA for bitcoin-development@lists.sourceforge.net; Sat, 01 Mar 2014 20:42:46 +0000 Received: by mail-yk0-f176.google.com with SMTP id 19so6179375ykq.7 for ; Sat, 01 Mar 2014 12:42:39 -0800 (PST) X-Received: by 10.236.129.36 with SMTP id g24mr66185yhi.103.1393706559151; Sat, 01 Mar 2014 12:42:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.170.99.66 with HTTP; Sat, 1 Mar 2014 12:42:18 -0800 (PST) In-Reply-To: <1393704464.6290.118.camel@mimiz> References: <1393704464.6290.118.camel@mimiz> From: Kevin Greene Date: Sat, 1 Mar 2014 12:42:18 -0800 Message-ID: To: Dev Random Content-Type: multipart/alternative; boundary=20cf300e576161246704f3919843 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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (kgreenek[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 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: 1WJqk8-0005rT-NA Cc: Bitcoin Dev 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 01 Mar 2014 20:42:46 -0000 --20cf300e576161246704f3919843 Content-Type: text/plain; charset=ISO-8859-1 Another example use-case to back up devrandom's point is using a twitter handle as the "merchant name". In that example, a 3rd party service hosts and signs the PaymentRequest, but when someone opens that PaymentRequest in their wallet, they should know that they are paying the specified twitter user. On Sat, Mar 1, 2014 at 12:07 PM, Dev Random wrote: > This looks like a good solution of the delegation use case for > medium/large businesses. > > I'm wondering about the small business case. A small business or an > individual might not have the technical expertise to perform the > delegation signature. Normally the X509 keys are squirreled away on the > merchant's web server and are not accessible through ordinary means. > And actually, the merchant might not even have a standalone web > presence. > > Do you think it makes sense to have another scheme where a merchant can > be name spaced under the payment processor? This would require just one > additional field - the merchant identifier. In effect, the PP would > certify that "PP / merchant-id" generated this invoice directly on the > PP system. > > On Fri, 2014-02-28 at 12:46 +0100, Mike Hearn wrote: > > 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.com and 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. > > > ------------------------------------------------------------------------------ > > Flow-based real-time traffic analytics software. Cisco certified tool. > > Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer > > Customize your own dashboards, set traffic alerts and generate reports. > > Network behavioral analysis & security monitoring. All-in-one tool. > > > http://pubads.g.doubleclick.net/gampad/clk?id=126839071&iu=/4140/ostg.clktrk > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -- > Miron > > > > --20cf300e576161246704f3919843 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Another example use-case to back up devrandom's point is using a twi= tter handle as the "merchant name". In that example, a 3rd party = service hosts and signs the=A0PaymentRequest, but=A0when someone opens that= PaymentRequest in their wallet, they should know that they are paying the = specified twitter user.


On Sat,= Mar 1, 2014 at 12:07 PM, Dev Random <c1.devrandom@niftybox.net> wrote:
This looks like a good solution of the deleg= ation use case for
medium/large businesses.

I'm wondering about the small business case. =A0A small business or an<= br> individual might not have the technical expertise to perform the
delegation signature. =A0Normally the X509 keys are squirreled away on the<= br> merchant's web server and are not accessible through ordinary means. And actually, the merchant might not even have a standalone web
presence.

Do you think it makes sense to have another scheme where a merchant can
be name spaced under the payment processor? =A0This would require just one<= br> additional field - the merchant identifier. =A0In effect, the PP would
certify that "PP / merchant-id" generated this invoice directly o= n the
PP system.

On Fri, 2014-02-28 at 12:46 +0100, Mike Hearn wrote:
> 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 dr= aw
> the line for v1 somewhere, and this is an issue that mostly affects > payment processors. But I figured I'd start a thread anyway becaus= e
> 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 propert= ies.
> 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: = =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<= br> > 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 {
> =A0 SECP256K1 =3D 1
> }
>
>
> message ExtensionCert {
> =A0 required bytes signature =3D 1;
> =A0 required bytes public_key =3D 2;
> =A0 required KeyType key_type =3D 3;
> =A0 required uint32 expiry_time =3D 4;
> =A0 optional string memo =3D 5;
> }
>
>
> // modification
> message X509Certificates {
> =A0 repeated bytes certificate =3D 1;
> =A0 repeated ExtensionCert extended_certs =3D 2;
> }
>
>
> message PaymentRequest {
> =A0 // new field
> =A0 optional bytes extended_signature =3D 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<= br> > 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, rat= her, it
> should be there for debugging purposes.
>
>
> The new ExtensionCert can then be provided back to the PP who adds it<= br> > to the X509Certificates message. In the PaymentRequest, there are now<= br> > 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<= br> > coinbase.com
>
>
> 2) Then sign again using the PP's delegated ECDSA key, i.e. sign a= s
> the merchant
>
>
> The finished protobuf would show up in old clients as signed by
> coinbase.com and= 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,<= br> > 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: =A0"x509+sha256+excert". Old wa= llets 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<= br> > 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<= br> > server can customise the PaymentRequest according to the capabilities<= br> > 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 thei= r
> 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 extens= ion,
> 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.
> ----------------------------------------------------------= --------------------
> Flow-based real-time traffic analytics software. Cisco certified tool.=
> Monitor traffic, SLAs, QoS, Medianet, WAAS etc. with NetFlow Analyzer<= br> > Customize your own dashboards, set traffic alerts and generate reports= .
> Network behavioral analysis & security monitoring. All-in-one tool= .
> http://pubads.g.doubleclick.ne= t/gampad/clk?id=3D126839071&iu=3D/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-d= evelopment@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitco= in-development

--
Miron




--20cf300e576161246704f3919843--