Seems good, I will merge it now in the interest of unbreaking things but I do think that we should switch to SHA2 asap. @schoen has some thoughts about whether it's worthwhile to combine SHA2 and SHA1 or not I think.

We chose to use the concatenation of md5 and sha1 because it was (1) decently secure and (2) more readily computable in client code. Though we could probably have grabbed a sha256 library.

Unfortunately the serverside code checks that the submitted certs have the same submitted fp as the server recomputes for them. So we'll need to set CertificateParser.skipfpcheck to True on the server if we want this to work.

Alternatively to the serverside kludge, we could use a JavaScript md5 implementation.

https://bugzilla.mozilla.org/show_bug.cgi?id=622332
https://hg.mozilla.org/mozilla-central/rev/f2a5edce0a57

This broke when FF32 released in September, so presumably everyone not running TBB / ESR has been not submitting to the Observatory since then :(

I don't think it's wise to ship a client that just uses sha1. It would create two populations of incompatible client submissions, meaning:

• we'd have to either turn skipfpcheck off forever, or have two different URL parameters for the fingerprint submissions (fp=MD5+SHA1&fp2=SHA1)
• features like this one would have to exist in two versions for the two client populations

So I've been trying to get md5 fingerprints going in pure JS. They don't match, yet...

@pde: Aha, I missed the fact that this is used as part of the certificate submission as well as for checking whether root CAs are public. What's the reason behind doing fp check?

Assuming we keep the fp check, I think the right thing to do is to add a new URL parameter.

It's okay if the whitelist updating breaks in older clients, since it's just a load reduction measure and the population of those clients is small.