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 1UVRb1-0005lr-Lb for bitcoin-development@lists.sourceforge.net; Thu, 25 Apr 2013 19:12:43 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.220.171 as permitted sender) client-ip=209.85.220.171; envelope-from=jeremy.spilman@gmail.com; helo=mail-vc0-f171.google.com; Received: from mail-vc0-f171.google.com ([209.85.220.171]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1UVRb0-0002eb-QP for bitcoin-development@lists.sourceforge.net; Thu, 25 Apr 2013 19:12:43 +0000 Received: by mail-vc0-f171.google.com with SMTP id ha12so563454vcb.16 for ; Thu, 25 Apr 2013 12:12:37 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.58.173.36 with SMTP id bh4mr13760245vec.9.1366917157280; Thu, 25 Apr 2013 12:12:37 -0700 (PDT) Received: by 10.58.137.197 with HTTP; Thu, 25 Apr 2013 12:12:37 -0700 (PDT) In-Reply-To: References: <20130425095855.GA30535@crunch> <20130425102853.GA31573@crunch> Date: Thu, 25 Apr 2013 12:12:37 -0700 Message-ID: From: Jeremy Spilman To: Bitcoin Dev Content-Type: multipart/alternative; boundary=047d7b5da81398e47204db343340 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 (jeremy.spilman[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: 1UVRb0-0002eb-QP Subject: Re: [Bitcoin-development] Cold Signing Payment Requests 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: Thu, 25 Apr 2013 19:12:43 -0000 --047d7b5da81398e47204db343340 Content-Type: text/plain; charset=ISO-8859-1 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 --047d7b5da81398e47204db343340 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
There are definitely ways to keep the pay-to address secur= e even if the web server is compromised, just perhaps not perfectly clean s= tandard X.509 ways under the current ecosystem which would be easier for ev= eryone to agree on.

=A0- If a more trusted cert is an EV end cert, and a l= ess trusted is a DV end cert (not chained off the EV) then it's easy fo= r the wallet to distinguish between the two, and they are both valid certs.= EV signs pubKey offline, DV used hot on the web server.
=A0- If the more trusted cert is an EV or DV end cert, and the l= ess trusted cert is chained off that end cert, it's technically 'in= valid' 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.
=A0- The third way is getting the pubKey into the cert att= ributes, 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 s= tolen.

On the wallet side, it comes down to = additional validation code paths which get triggered by some detection logi= c. For example, if you pass PubKey and InvoiceID in the Payment Request, th= e wallet needs to know if it should check for a Subject Alternate Name in t= he cert for a fingerprint of the PubKey, how the fingerprint is calculated,= and then verify the Address is indeed PubKey * InvoiceID. =A0I think false= ly rejecting a legacy Payment Request would get the extra validation code p= ath commented out pretty quickly.

I really like Mike Hearn's idea of 'You h= ave paid this recipient 4 times' but also agree completely on the cryin= g wolf due to expiration or revocation. At least such a message could be ba= sed on the domain name only, to try to prevent phishing with similar domain= names, then there's no expiration issue. Slightly more restrictive wou= ld be domain + CA, again not considering expiration, but pinning the pay co= unt to the CA seems to have little downside and makes it harder for an atta= cker to get their own cert for your domain if you choose your CA 'wisel= y'.

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 s= tart 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 w= orking 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. = =A0Gavin, would the best way to work on this be to just fork your code on G= ithub?

Thanks,
--Jeremy
--047d7b5da81398e47204db343340--