support auto-update of notary_list

[danwent]

A key criteria is that we should strongly validate the security of the downloaded data, such that even if someone has compromised a CA, they cannot spoof a valid notary list.

We could do this either by signing the data at the application layer, or by hardcoding the fingerprint for a known website (e.g., www.networknotary.org) and using https://developer.mozilla.org/En/How_to_check_the_security_state_of_an_XMLHTTPRequest_over_SSL . Note that hardcoding the fingerprint breaks if you ever change the cert on the websever.

[andrewgdotcom]

How do you handle notary public key distribution at the moment? It would appear to be the achilles heel of the system.

[danwent]

Currently, a static list of notaries and their public keys is shipped with the Perspectives code. I don't see this as a particular weakness of Perspectives (in fact, this is exactly how a browser like Firefox distributes CA certificates). With any security tool, you need to make sure you are getting a genuine copy of the software, otherwise all bets are off :)

As a side note, I've actually implemented a preliminary version of the functionality above. Essentially, Perspectives would ship with a single trusted key (instead of a list) and this trusted key would be used to validate a list of notaries that can be downloaded at a later point (this mechanism does not rely on the browser using SSL, so my original comments above do not apply. This gives us the same security model, but with the flexibility to changing the set of servers without having to push a new version of the code through the firefox approval process.

[daveschaefer]

@danwent @andrewgdotcom @lambdor So this is a very old ticket - I vote to delete this functionality altogether.

###Arguments for deletion:

1. Updating default notaries is not something we need to do with critical speed or to suddenly fix security issues
2. It may be confusing to suddenly alter this behaviour behind the scenes. Changing notaries is an action that should have explicit consent from the user
3. We already have an update mechanism - publishing releases on addons.mozilla.org. No need to support an extra code path to do the same thing or to maintain a separate server just for updates
4. The default notary list should not change frequently; we should run a stable set of notaries (still a work in progress :-/) and don't need to regularly change it
5. This feature has never been enabled and we've gotten along fine without it.

###Arguments to keep:

1. If we expand to further browsers in the future it may be that we need to quickly update the notary list for some reason?

Do we really need an alternate update method rather than going through addons.mozilla.org? When this bug was created Perspectives may (?) have been distributed through Dan's personal site. But now we only distribute from addons.mozilla.org and no other sites.

If it's not active code it makes the codebase easier to read and maintain by just deleting it. I vote we kill it.

Any thoughts?

[ghost]

It may be confusing to suddenly alter this behaviour behind the scenes. Changing notaries is an action that should have explicit consent from the user

+1 for removal I don't like the idea either. Auto-updates are a potential security issue.