End-to-End Encryption for Credit Card Payments

I would like to know what Nate Lawson thinks about this, as he wrote a really long post explaining why (his words¹) "client-side JS crypto is a bad idea"².<p>¹ <a href="http://rdist.root.org/2011/05/09/encrypted-google-docs-done-well/" rel="nofollow">http://rdist.root.org/2011/05/09/encrypted-google-docs-done-...</a><p>² <a href="http://rdist.root.org/2010/11/29/final-post-on-javascript-crypto/" rel="nofollow">http://rdist.root.org/2010/11/29/final-post-on-javascript-cr...</a>

Does the PCI standard make any tangible differentiation between having unencrypted versus encrypted credit information pass through my system?<p>The major advantage of the transparent redirect and similar implementations at other providers is that the data doesn't pass through my server at all. To me this always seemed like a bit of a loophole in PCI compliance. My server that serves up the form which, if hacked, could easily be modified to send credit card details to an attacker is out of scope because it doesn't technically, "accept, transmit or receive" as worded in the PCI docs. Does receiving the data in encrypted format still afford me use of the loophole or are the PCI requirements more stringent than when using transparent redirect?

Can't quite grok it on this post, but where they describe "end-to-end", how exactly are keys generated and distributed? Are key fingerprints verified out of channel? How are they not susceptible to MITM attacks? Which, admittedly may be difficult, but still possible. How is this any better than sending CC data from browser to server via SSL, which at least has a CA system (as shitty as the whole CA thing is)???

I really could have used this three years ago when I posted this question to Stack Overflow:<p><a href="http://stackoverflow.com/questions/205468/how-to-encrypt-a-value-on-the-client-and-pass-it-through-a-web-server-without-dec" rel="nofollow">http://stackoverflow.com/questions/205468/how-to-encrypt-a-v...</a><p>I don't really need the answer now, but I bet my old boss would be interested in this development...

Never thought of doing public key cryptography in JavaScript. A quick Google brings up this RSA implementation: <a href="http://www.ohdave.com/rsa/" rel="nofollow">http://www.ohdave.com/rsa/</a>

What stops the site owner from tracking keystrokes?

Why has someone not mashed up oAuth with online payments? I think it'd be a fun idea.