Re: [Bitcoin-development] Cold Signing Payment Requests
(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
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
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
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
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] Cold Signing Payment Requests
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
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
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
