BrowserID: A new web authentication scheme
Posted Jul 28, 2011 6:49 UTC (Thu) by JohnLenz
Parent article: BrowserID: A new web authentication scheme
For the revocation, one option would be to use DNS and dnssec. DNSSEC has done all this hard work, it contains key signing keys and zone signing keys and contains methods for continuously rolling keys. One option would be for an authority like browserid.org to just use the zone signing key as the key it uses to sign the users public keys.
This seems like it would work well since most ZSK's are rolled on a one-week interval. The user would store their public and private keys plus a signature of their public key using the authorities current ZSK. The user would need to periodically refresh the signature through communication with the authority (which could be done automatically in the background or re-request the password or whatever method the authority chooses.) To log in, the user sends the public key plus the signature using the ZSK and the server uses DNSSEC to lookup (and cache) the authorities ZSK. The server can now verify the user and knows the user has authenticated with the authority recently since otherwise the ZSK would have rolled away.
Using the ZSK as the authorities public key also has the added advantage that login can proceed even if the authority site is temporarily down, since DNS is built with redundant servers and caching.
In any case, I would think fleshing out the above issues is a requirement before browser id has any chance at taking off. I know for me I wouldn't consider making browser id the only method of logging in unless it had some provision for a verification process to proceed when the third-party sites are temporarily down like storing the keys in DNS or something like that.
to post comments)