This post is in response to a tweet by @francesIDexpert who asked: “For those of you following #NSTIC, what do you think about this http://t.co/zUErAzZ”, where the shortened link refers to an article on BrowserID.
Here is my take on BrowserID and the Verified Email Protocol that it is based on. The functionality provided by an “IDBrowser Primary Authority” is equivalent to the functionality that would be provided by a certificate authority (CA) that would issue to a user a PKI certificate binding a public key to an email address, the CA being the email service providing the address.
I see two positives and one negative in BrowserID. The positives are:
- Having an email service provider issue email-address certificates, and
- Having the certificates issued automatically.
The negative is that BrowserID reinvents the wheel. There is no need for a new type of certificate, a new certificate store in the browser and a Javascript API for submitting certificates to a relying party, when an email address can be carried in an ordinarly PKI certificate, which a browser can store and present to a relying party as a TLS client certificate.
Now to NSTIC.
An explicit privacy goal of NSTIC is that colluding relying parties should not be able to use the user’s credentials to track the user. That is, two different relying parties should not be able to tell that the same user has logged in to both of them by comparing their login logs. Using an email address as an identifier is incompatible with this goal.
One could argue that relying parties need the user’s email address anyway. That’s true today, because email is often used to recover from forgotten passwords. But another goal of NSTIC is to provide alternatives to passwords. Without passwords, many relying parties will have no valid reason to ask for an email address. (And there will consequently be less spam.)
So an email-address certificate is a good way of demonstrating ownership of an email address to a relying party with a legitimate need to know the address. Actually, I will incorporate that idea into our proposed NSTIC architecture (with proper credit, of course) at the very next revision of the white paper. But an email address is not a good idea as a universal identifier for the Web.
Hi,
I tend to think that the new certificate format using JSON could be a very interesting move in that it makes certificates a lot less magical to developers. ASN.1 is just difficult to use – and the APIs for working with it are rarely that good. But then the APIs could be improved a little, and no body would be the wiser, and it would avoid two certificate formats needing to be kept in sync in the browser.
The other advantage of BrowserId is that it finds a way to send a certificate to web sites without requiring them to have TLS. Many sites don’t have TLS , and until DNSsec rolls out and the IETF Dane working group allows self-signed certs to be placed into DNS, getting certificates for web sites is still a process that requires an unnecessary man in the middle. So as the BrowserId team have shown, it is extremely easy for sites to deploy BrowserId. Add a bit of javascript here and do a bit of simple crypto there, and all is done — of course there are many unknown as far as security go, since it is new.
On the other hand inventing a new certificate format, has it’s own issues.
For WebID which uses X509 certificates ( http://webid.info/ ) this could be very helpful to get going, in that it could enable any site to get http(s):// identifiers. The advantage of those identifiers is that they are not prone to spam. They are linkable which in our view is a plus, as it allows one to build a distributed Social Web, and so remove the massive privacy intrusion that one gets otherwise by creating monoliths such as Facebook that end up seeing everything that everybody is writing about.
The WebID protocol is being developed at the W3C. I think it would be very interesting to have you present some of your ideas there sometime.
I agree with your thoughts on certificate syntax. Regarding sites that do not use TLS: I was assuming that BrowsedID would want the relying party to use TLS, otherwise there can be no security; for example, a man-in-the-middle attack can intercept the authentication cookie that the relying party presumably sets in the browser after user authentication.
Regarding WebID, after watching your WebID video, it seems WebID certificates would fit nicely in the NSTIC architecture that we are proposing as one possible kind of credential. I would be happy to brainstorm about this with the WebID community.
“a Javascript API for submitting certificates to a relying party” is not a bad thing. it is actually a good thing. Imagine you are a web developer. That means you know about html, javascript and css. Maybe some php/ruby/etc. and mysql/mongo/etc.
Now you want people to log in to your website, easily and securely. You also have a deadline for launching the website, which is coming closer. Your client only cares about whether it works. In that situation, most web devs will choose BrowserId over anything that requires them to integrate their javascript and php code with the webserver’s TLS layer.
So from the point of view of a relying party, how is the javascript API a bad thing?
I didn’t say the javascript API is a bad thing, did I? I said that was it reinvented the wheel — maybe that was unfair, since it’s an alternative that may be come in handy in some cases, as you explain. But I stand by the fact that there is a standard way of submitting client certs, via TLS, which does not require JavaScript to be enabled in the browser, and which is probably more secure. (I say “probably more secure” because BrowserID security has received much less scrutiny than TLS security.) Also, integration with the TLS layer is not difficult, is it? In Apache, for example, mod_ssl takes care of obtaining the client certificate, parsing it, and delivering its contents in environment variables, as you can see at http://httpd.apache.org/docs/2.0/mod/mod_ssl.html. A PHP developer can access the environment variables through the $_ENV array.