Comments on: JavaScript and crypto

By: davidillsley

davidillsley — Tue, 30 Aug 2011 21:51:03 +0000

Sure, but it’s easy enough to serve up JS in an iframe which sends the result of getPublicKey back to the server.

My gut feel is:
– that there shouldn’t be a getPublicKey, or it should take the ID as a param
– that generateKeyPair should be (more clearly) specced to overwrite any existing key
– that private browsing mode behaviour should be specced – presumably the obvious behaviour

Another spec thought..
– the encrypt/decrypt/sign/verify calls should have a defined backoff to prevent guesses at the keyID

By: ddahl

ddahl — Tue, 30 Aug 2011 21:21:55 +0000

It is still unclear whether or not we will need to have getPublicKey() as generateKeyPair() will return the public key when the keypair is generated. Something to keep in mind: the public key for foobar.com can only be used on foobar.com. Each user will have a unique public key for each domain where the API is used – in which case, there is not a “super cookie”. The current extension (prototype) implementation has only a single keypair, which could be used for tracking.

By: davidillsley

davidillsley — Tue, 30 Aug 2011 20:56:47 +0000

I like the way this has progressed… very focused on providing something simple and coherent.
I’ve got a quick question…

What’s the plan around privacy/identification? getPublicKey() looks like it provides a powerful user tracking feature.