- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Tue, 21 Oct 2008 09:43:38 -0500
On Tue, Oct 21, 2008 at 9:36 AM, Eduard Pascual <herenvardo at gmail.com>wrote: > On Tue, Oct 21, 2008 at 2:16 PM, Aaron Swartz <me at aaronsw.com> wrote: > > My proposal: add something to HTML5 so that the transaction looks like > this: > > > > Client: GET /login > > Server: <html><form method="post" pubkey="/pubkey.key">... > > Client: POST /login > > dXNlcj1qb2VzbWl0aDAxJnBhc3N3b3JkPXNlY3JldA== > > Server: 200 OK > > Set-Cookie: acct=joesmith01,2008-10-21,sj89d89asd89s8d > > > > where the base64 string is the form data encrypted with the key > > downloaded from /pubkey.key. This should be fairly easy to implement > > (for clients and servers), falls back to exactly the current behavior > > on browsers that don't support it, and solves a rather important > > problem on the Web. > What's the actual difference between this and https? Both mechanisms > are using public-key encryption to protect the communications; the > only difference being that with https the encryption is handled at the > protocol level; while your suggestion would (currently) require to > reinvent the wheel, encrypting the data on the client (maybe using > JavaScript?) and then decripting it on the server (probably via > server-side scripting). > Maybe there is a good point on that suggestion, and I'm simply failing > to see it. If that's the case, I invite you to enlighten me on it. > I agree in general with the criticisms raised here, but I'll correct a small point in your post. The goal for this is to *not* require authors to do any client-side encrypting, but for the UAs to encrypt instead. It would then be the responsibility of the author to decrypt on the server side. ~TJ -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20081021/1e85a47f/attachment.htm>
Received on Tuesday, 21 October 2008 07:43:38 UTC