I like the idea, but I too have many questions left open. Please do not see this as any form of bashing, because I wrote it trying to apply my authentication experience to this new scheme.
I am concerned about (in no particular order) :
- Unauthorized use of the private key
- Rich client support (Outlook, Notes, etc.)
- Using from multiple computers
- Private key protection or encryption (on the client)
- Authentication of key generation requests
Details below. First a one line summary (in bold italic) and some clarifications.
1. Unauthorized use of the private key
The private key will be protected by the client, with varying degrees of security.
I am worried that any the private key will be used without my consent. When trying to authenticate, a signing operation will take place. I must be prompted before it is used, or else a rogue script could get my browser to sign a logon ticket and submit it. Rogue script could come from a widget, add or other XSS. Implementation of this mechanism will vary in every browser, and even on different platforms for the same browser, or different versions, etc. With a somewhat inconsistent visual, users are at a greater risk to being lured to approve a logon request.
2. Rich client support (Outlook, Notes, etc.)
It was desinged to work with web mail accounts. Enterprise "fat" mail clients are somewhat left behind.
Users in a corporate environment who use fat mail client (Outlook, Notes, Thunderbird) will be late adopters, because the protocol will have to be implemented in those clients too. Not to mention that Outlook does not share a keystore with Firefox, or Thunderbird with IE.
3. Using from multiple computers
It leads to a proliferation of private keys, because the scheme does not to have a central authority.
And there is a mobility problem. I will have to register (generate a private key) for every computer I use. How will I go about deleting my private key in an internet kiosk, or a borrowed computer ? Even with a single computer, how will I revoke a key stored in a stolen computer ? Since for a single user, multiple signature keys are valid (because each of my computers have its own valid private key), from the service provider point of view, any access token signed by a known authority must be valid.
4. Private key protection or encryption (on the client)
Access to the key must be authenticated, which brings passwords back in the picture.
It can protected by a password (limiting its malicious reuse), but if I ever change my password somewhere, it will not synchronize unless I use some browser/cloud based sync network. Having a password to remember somewhat defeats the purpose of this scheme. Chances are the same password will be used to secure every key, much like the same password is used now to authenticate to multiple websites.
5. Authentication of key generation requests
There is a gap between the access request and key generation, wich an attacker could use for phishing.
It is unclear to me how the email provider/certificate authority will handle CSRF issues. How will they know that a request for key generation is legitimate ? Will my spam folder be filled with certificate generation requests ? Or will key issued only with DKIM email servers ? What if the request was intercepted on its SMTP way to the server, could it be modified ?
Using a tag allows browserid.org to break the same origin policy.
And using a script tag to include the browserid.js allows them to bypass the same origin policy. BrowserID.org will (have the power to) know about every logon attempt you make. Or you will have to host the script yourself (assuming it is self contained), and upgrade it if/when security flaws will be identified in it.