Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-25 Thread Mike Hearn
(for background: I did a lot of the design work with Gavin on the payment
protocol and suggested/prototyped using x.509 in the way we do).

So, I'm not a fan of weird hacks involving non-existent domain names.
There's a clean way to implement this and we decided to punt on it for v1
in order to get something shippable, but if you're volunteering ... :) then
indeed having a custom cert type that chains onto the end is the way to go.

It doesn't have to be X.509. It can just be a regular protocol buffer. Even
if we re-used X.509 it wouldn't be accepted by OpenSSL or any other SSL
stack, so it wouldn't buy us anything and it's not like ASN.1 is easy to
work with. Chaining an additional Bitcoin-specific cert onto the end also
solves the problem of delegation ... a lot of merchants are using BitPay
but probably don't want to share their SSL private keys with a third party.
That means today the payments would show up as paid to BitPay Inc which is
misleading and weird, they're just an intermediary. So if the merchant can
run a simple command line tool that you point to the private key, and it
spits out a signed protobuf that contains a new (ecdsa) public key and
saves the private key to a file, then you can send that cert and key off to
your payment processor. The identity is still taken from your CA cert but
the actual signing keys used are different.

Another use case - a company has a lot of roving sales agents, like in a
supermarket or waiters at a restaurant. The company wants the agents to be
able to sign with their corporate EV identity but the agents are not highly
trusted. So they can be issued a 24-hour expiring Bitcoin-specific cert at
the start of each working day and then they sign payment requests with that.
--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-25 Thread Timo Hanke
 So, I'm not a fan of weird hacks involving non-existent domain names.
 There's a clean way to implement this and we decided to punt on it for
 v1 in order to get something shippable, but if you're volunteering ...
 :) then indeed having a custom cert type that chains onto the end is
 the way to go.

Chaining a custom cert onto the end doesn't work, at least not if your
end is the SSL cert. Chaining it to the SSL cert defeats the OP's
intention of cold signing, as the SSL private key is usually kept
online, therefore can't be used to sign a pubkey that is supposed to
stay offline. Hence the idea of the hack, to get two independent
things signed by the CA in just one cert: 1) your SSL pubkey, 2) your
custom cert (by including its cryptograhic hash). This hack seems the
easiest possible solution.

It also seems the only solution if you want to stick with domain-names
as identifiers for the payment protocol (and I think you do). A cleaner
way would be to get a cert signed by your CA that contains an extended
bitcoin attribute in compliance with X.509, but this seems a little
far off.

So I am in favor of the hack (properly thought out where to place the
hash).

ps. In the long run I would of course like to see payee identities based
on alt-chains rather than domain-names plus CAs. But that's rather a
concern for v3 than v2. Of course, you can also chain custom certs to
non-SSL identities like PGP-keys. You probably don't want to do that,
but it would solve Melvin Carvalho's problem of sending to RSA keys
(assuming the RSA key holder previously published his custom cert with a
cert server). 

-- 
Timo Hanke
PGP AB967DA8, Key fingerprint = 1EFF 69BC 6FB7 8744 14DB  631D 1BB5 D6E3 AB96 
7DA8

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-25 Thread Mike Hearn
 Chaining a custom cert onto the end doesn't work, at least not if your
 end is the SSL cert. Chaining it to the SSL cert defeats the OP's
 intention of cold signing, as the SSL private key is usually kept
 online, therefore can't be used to sign a pubkey that is supposed to
 stay offline.


What you wrote doesn't make any sense to me, sorry.

Yes, SSL private keys are kept online. That's irrelevant - the goal of all
this is not to protect against web server compromise. That's a pointless
goal to try and solve right now, because the SSL PKI cannot handle
compromised web servers and so neither can we (with v1 of the payments
spec).

The goal of this is to allow delegation of signing authority without giving
the delegate the SSL private key.
--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-25 Thread Timo Hanke
On Thu, Apr 25, 2013 at 12:05:06PM +0200, Mike Hearn wrote:
 Chaining a custom cert onto the end doesn't work, at least not if your
 end is the SSL cert. Chaining it to the SSL cert defeats the OP's
 intention of cold signing, as the SSL private key is usually kept
 online, therefore can't be used to sign a pubkey that is supposed to stay 
 offline.
i meant:  ^whose privkey is 
supposed to stay offline.

 the goal of all this is not to protect against web server compromise.

 The goal of this is to allow delegation of signing authority without giving 
 the
 delegate the SSL private key.

This is not how I understand the OP, which I said I was addressing:

 The difficulty is that Payment Requests must be generated live, and
 therefore the key used to sign those requests must also be live,
 exposing the key to theft similar to a hot wallet. Steal the key,
 forge payment requests, and the payer sees a 'green box' but the coins
 go to the attacker. The question... is there a way to sign something
 once, with a key kept offline, which verifies the address in the
 Payment Request belongs to the payee?



 That's a pointless goal to try and solve right now, because the SSL
 PKI cannot handle compromised web servers and so neither can we (with
 v1 of the payments spec).

I don't think the OP intended to solve it right now, i.e. in v1. 

He differentiated between most trusted and less trusted keys
(certs). So he can clearly live with the SSL PKI being less trusted
for his purpose.  

-- 
Timo Hanke
PGP AB967DA8, Key fingerprint = 1EFF 69BC 6FB7 8744 14DB  631D 1BB5 D6E3 AB96 
7DA8

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-25 Thread Mike Hearn

  That's a pointless goal to try and solve right now, because the SSL
  PKI cannot handle compromised web servers and so neither can we (with
  v1 of the payments spec).

 I don't think the OP intended to solve it right now, i.e. in v1.

 He differentiated between most trusted and less trusted keys
 (certs). So he can clearly live with the SSL PKI being less trusted
 for his purpose.


Yes, but my point is if the SSL key lives on the web server, and there are
CAs that issue you certs based on control of a web server at the given
domain name (there are), then you can simply issue yourself a new SSL cert
with whatever data in it you want and pose as the merchant.

So I don't see how you can have a payment request signing key that's safer
than an SSL key. As Jeremy notes, CAs will not issue you intermediate
certificates. Perhaps if one existed that would do the necessary things for
a reasonable price you could indeed give yourself an offline intermediate
cert and then use that to sign one cert for SSL and another for payment
request signing, but as far as anyone is aware no such CA exists.

The interesting case is where the thing signing payment requests is less
trusted than the web server. The scenario you're trying to solve is the
inverse - the payment request signing process is more trusted than the web
server. But unless/until the CA landscape changes we don't have a way to
implement that.
--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] [Bitcoin-test] Time for a 0.8.2 release

2013-04-25 Thread Arklan Uth Oslin
unfortunately my winter has proven a complicated series of significant life
events - new work, etc - which sees me with little free time to help out.
sorry.


Arklan

--
As long as there is light, the darkness holds no fear. And yet, even in the
deepest black, there is life. - Arklan Uth Oslin

I want to leave this world the same way I came into it: backwards and on
fire. - Arklan Uth Oslin


On Wed, Apr 24, 2013 at 9:22 AM, Gavin Andresen gavinandre...@gmail.comwrote:

 Consensus in #bitcoin-dev chat is that it is time to do a 0.8.2 release. A
 few important bugs have been fixed, and the goal will be to get a 0.8.2
 final release before the May 15'th hard fork deadline.

 Pieter has already started going through the issues list; help with
 testing, debugging, and fixing high-priority issues is very welcome. I'll
 also be going through the issues list and marking any issues I think need
 to be fixed with the '0.8.2' milestone.

 If translation work needs to be done, now is a great time to do it.

 We still don't have a basic QA checklist for testing of release
 candidates; I'll commit to spending a little of the remaining Bitcoin
 Testing Project bitcoins to whoever contributes to creating one.

 --
 --
 Gavin Andresen


 --
 Try New Relic Now  We'll Send You this Cool Shirt
 New Relic is the only SaaS-based application performance monitoring service
 that delivers powerful full stack analytics. Optimize and monitor your
 browser, app,  servers with just a few lines of code. Try New Relic
 and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr
 ___
 Bitcoin-test mailing list
 bitcoin-t...@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-test


--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-25 Thread Mike Hearn
On Thu, Apr 25, 2013 at 4:13 PM, Mike Caldwell mcaldw...@swipeclock.comwrote:

 I am not sure if my replies hit the list. If not, can anyone who sees this
 help?

 In the past, I have pre signed (with PGP) large batches of Bitcoin
 addresses for distribution on my server. This way, even in the event of
 compromise, there is no way someone could substitute an address of their
 own and have it have the same characteristics as other addresses I have
 signed.  The same general concept could be used to keep signing keys off
 the web server.

 Mike


I didn't see your other replies but got this one.

The assumption you made by doing that is that people can obtain your PGP
key. This leads to the question of how someone knows what your key is or
that you signed the list in the first place. The most obvious way is to go
to https://www.casascius.com/ and click My PGP key - but we already
failed at this point if your web server was hacked. I'd have to learn about
your cryptographic identity via some other secure channel, but usually that
doesn't exist.

Being able to survive web server hacks is intuitively attractive because
web servers tend to be so insecure. But unfortunately there doesn't seem to
be any good way to do this with todays infrastructure because for most
businesses, their website *is* their identity, and if a hacker controls
that they it's very hard for anyone (including CAs) to know that something
has gone wrong.

I think there are some simple mitigations we can use in the short term.

One is that wallets could count how many times you paid to addresses signed
by a particular cert. If you're a repeat customer and your wallet says You
have never paid this recipient before instead of You have paid this
recipient 4 times then you might be suspicious. Someone pointed out to me
that the current payment protocol has nothing to say on phishing using
confusible domains - this could help with that too, and it's easy to
implement. Of course it means you get reset whenever your certificate
expires and has to be renewed, and crying wolf is often worse than doing
nothing at all. So that's an issue.

With time there might be more complex solutions available, like extensions
to X.509/CA infrastructure (if bitcoin stays growing and popular). Also,
alternative PKIs like DNSSEC or the ePassport PKI might be useful. In your
case Mike you aren't really a company, you're trading under your own name,
so signing the key list under your legal identity is really the best
solution. It's just not easily available right now.
--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-25 Thread Jeremy Spilman
There are definitely ways to keep the pay-to address secure even if the web
server is compromised, just perhaps not perfectly clean standard X.509 ways
under the current ecosystem which would be easier for everyone to agree on.

 - If a more trusted cert is an EV end cert, and a less trusted is a DV end
cert (not chained off the EV) then it's easy for the wallet to distinguish
between the two, and they are both valid certs. EV signs pubKey offline, DV
used hot on the web server.
 - If the more trusted cert is an EV or DV end cert, and the less trusted
cert is chained off that end cert, it's technically 'invalid' so again its
obvious which one is more/less trusted, but it's easier for an attacker to
get their own DV end cert for your domain.
 - The third way is getting the pubKey into the cert attributes, such as
encoding the pubKey, or a fingerprint of the pubKey, as a Subject Alternate
Name, so the attacker would need to get their own cert to change the
address, meaning it's not as critical if your cert key is stolen.

On the wallet side, it comes down to additional validation code paths which
get triggered by some detection logic. For example, if you pass PubKey and
InvoiceID in the Payment Request, the wallet needs to know if it should
check for a Subject Alternate Name in the cert for a fingerprint of the
PubKey, how the fingerprint is calculated, and then verify the Address is
indeed PubKey * InvoiceID.  I think falsely rejecting a legacy Payment
Request would get the extra validation code path commented out pretty
quickly.

I really like Mike Hearn's idea of 'You have paid this recipient 4 times'
but also agree completely on the crying wolf due to expiration or
revocation. At least such a message could be based on the domain name only,
to try to prevent phishing with similar domain names, then there's no
expiration issue. Slightly more restrictive would be domain + CA, again not
considering expiration, but pinning the pay count to the CA seems to have
little downside and makes it harder for an attacker to get their own cert
for your domain if you choose your CA 'wisely'.

I assume the ship has sailed on v1, but if we can get consensus on how we
want this to work in the near-term, we can start prototyping it and maybe
get this available sooner than later. In any case we should be confirm v1
doesn't do anything to prevent this from working in a clean, extensible
manor, which I think means prototyping it and seeing the new Payment
Request is handled transparently by v1 code.

Right now I'm leaning towards writing a prototype using a single cert with
a fingerprint of PubKey in the Subject Alternate Name, and getting PubKey
and InvoiceID in the Payment Request.  Gavin, would the best way to work on
this be to just fork your code on Github?

Thanks,
--Jeremy
--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-25 Thread Gavin Andresen
On Thu, Apr 25, 2013 at 3:12 PM, Jeremy Spilman jeremy.spil...@gmail.comwrote:

 Right now I'm leaning towards writing a prototype using a single cert with
 a fingerprint of PubKey in the Subject Alternate Name, and getting PubKey
 and InvoiceID in the Payment Request.  Gavin, would the best way to work on
 this be to just fork your code on Github?


As usual, our bottleneck is code review / testing, so it would be nice if
you spent some time reviewing code and helping test v0.9 so we can actually
ship a v1 sometime in the next several months before you start working on a
v2.

-- 
--
Gavin Andresen
--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development