summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAndreas Schildbach <andreas@schildbach.de>2014-03-02 16:20:34 +0100
committerbitcoindev <bitcoindev@gnusha.org>2014-03-02 15:20:54 +0000
commit828451fd7be8aa802d6d04e178c0827522815b63 (patch)
tree862bbc8953956960049ecd9631cfb508954ee76b
parent47de8081a060d5bbc7c0281d1f813995df6f9e12 (diff)
downloadpi-bitcoindev-828451fd7be8aa802d6d04e178c0827522815b63.tar.gz
pi-bitcoindev-828451fd7be8aa802d6d04e178c0827522815b63.zip
Re: [Bitcoin-development] BIP70 extension to allow for identity delegation
-rw-r--r--55/61ba3ade88b1f4b1ae7c3a87b5c78de767a450252
1 files changed, 252 insertions, 0 deletions
diff --git a/55/61ba3ade88b1f4b1ae7c3a87b5c78de767a450 b/55/61ba3ade88b1f4b1ae7c3a87b5c78de767a450
new file mode 100644
index 000000000..be2464085
--- /dev/null
+++ b/55/61ba3ade88b1f4b1ae7c3a87b5c78de767a450
@@ -0,0 +1,252 @@
+Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
+ helo=mx.sourceforge.net)
+ by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
+ (envelope-from <gcbd-bitcoin-development@m.gmane.org>)
+ id 1WK8CE-0002R6-UC for bitcoin-development@lists.sourceforge.net;
+ Sun, 02 Mar 2014 15:20:54 +0000
+Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of m.gmane.org
+ designates 80.91.229.3 as permitted sender)
+ client-ip=80.91.229.3;
+ envelope-from=gcbd-bitcoin-development@m.gmane.org;
+ helo=plane.gmane.org;
+Received: from plane.gmane.org ([80.91.229.3])
+ by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
+ (Exim 4.76) id 1WK8CD-0005EC-0q
+ for bitcoin-development@lists.sourceforge.net;
+ Sun, 02 Mar 2014 15:20:54 +0000
+Received: from list by plane.gmane.org with local (Exim 4.69)
+ (envelope-from <gcbd-bitcoin-development@m.gmane.org>)
+ id 1WK8C5-0004ig-ND for bitcoin-development@lists.sourceforge.net;
+ Sun, 02 Mar 2014 16:20:45 +0100
+Received: from f053042016.adsl.alicedsl.de ([78.53.42.16])
+ by main.gmane.org with esmtp (Gmexim 0.1 (Debian))
+ id 1AlnuQ-0007hv-00 for <bitcoin-development@lists.sourceforge.net>;
+ Sun, 02 Mar 2014 16:20:45 +0100
+Received: from andreas by f053042016.adsl.alicedsl.de with local (Gmexim 0.1
+ (Debian)) id 1AlnuQ-0007hv-00
+ for <bitcoin-development@lists.sourceforge.net>;
+ Sun, 02 Mar 2014 16:20:45 +0100
+X-Injected-Via-Gmane: http://gmane.org/
+To: bitcoin-development@lists.sourceforge.net
+From: Andreas Schildbach <andreas@schildbach.de>
+Date: Sun, 02 Mar 2014 16:20:34 +0100
+Message-ID: <levi7k$pkt$1@ger.gmane.org>
+References: <CANEZrP1eABw_x8o-Z9ac23e-dVvUWfZJ-hKfAak=-NicPhUv9g@mail.gmail.com>
+Mime-Version: 1.0
+Content-Type: text/plain; charset=ISO-8859-1
+Content-Transfer-Encoding: 7bit
+X-Complaints-To: usenet@ger.gmane.org
+X-Gmane-NNTP-Posting-Host: f053042016.adsl.alicedsl.de
+User-Agent: Mozilla/5.0 (X11; Linux x86_64;
+ rv:24.0) Gecko/20100101 Thunderbird/24.3.0
+In-Reply-To: <CANEZrP1eABw_x8o-Z9ac23e-dVvUWfZJ-hKfAak=-NicPhUv9g@mail.gmail.com>
+X-Spam-Score: -0.4 (/)
+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 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
+ no trust [80.91.229.3 listed in list.dnswl.org]
+ -0.0 SPF_HELO_PASS SPF: HELO matches SPF record
+ 1.1 DKIM_ADSP_ALL No valid author signature,
+ domain signs all mail
+ -0.0 SPF_PASS SPF: sender matches SPF record
+ -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
+ domain
+X-Headers-End: 1WK8CD-0005EC-0q
+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 15:20:55 -0000
+
+I somehow think that it is too early for this heavy kind of extension,
+given that the first version of BIP70 isn't even deployed widely let
+alone *used*.
+
+By reading your proposal I get the idea that the current spec doesn't
+allow two (or three) different PKIs at once -- we would want this for
+migration purposes as you wrote and also because different people prefer
+different kinds of PKIs. And that's perhaps something we want to fix in
+the current (version 1) spec to prevent us running into a wall and be
+doomed to patch around the spec. Note I assume a potential PGP or
+Bitcoin-based infrastructure would also be called 'PKI'.
+
+I would prefer if your fix would stay local to X.509 (and thus only
+change X.509 specific structs rather than the top-level PaymentRequest).
+And for a future PKI we would implement identity delegation in a
+straight forward, non-kludgy way.
+
+
+On 02/28/2014 12:46 PM, 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 <http://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 <http://coinbase.com> and by new clients as signed by
+> overstock.com <http://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
+>
+
+
+
+