816 karma · joined September 15, 2012
Your URL structure suggests you may be planning to do this for other Apollo missions, is that in the cards?
Edit: I see you've done this for Apollo 17 already on a different URL: https://apollo17.org/
This has been generally accepted (via discussions on MDSP and in the CABForum itself) to mean that the serial must contain at least 64-bits of entropy. Not that the generation process consumes 64-bits. If it was the latter then `head -c 8 /dev/urandom | head -c 1` (and clamping the top bit to 0) would be a permissible method of generating a serial since it consumes 64-bits of CSPRNG output to generate the serial number.
CAs are given enormous power in the ecosystem and we judge them based on their incident response and process improvement. The barrier to entry should be very high for new entrants as we strive to improve the state of the industry. This incident alone is not a disqualifier for DM's inclusion but should be considered in the context of the other issues (both technical and otherwise) raised during review of the application process.
Regarding your claim that all certificates with 64-bit serial numbers are guaranteed invalid: A certificate with a 64-bit serial MAY be valid under the standard because a CA might choose to implement the spec such that they generate a serial and prepend a null byte if and only if the high bit is 1. To determine whether or not a CA is doing that experimentally you could use services like crt.sh or censys to find all CAs with valid 64-bit serial number certificates and see if they also issue 72-bit serial numbers. If you don't see any >64-bit they're likely violating the BRs and you should submit a report to them (Mozilla maintains a contact list for CAs on their wiki) and also send an email to MDSP. Independent researchers are the lifeblood of the current wave of enforcement across the industry!
The GFW is not a monolithic entity though so be aware that performance and blocking characteristics can vary widely between cities, ISPs, and sometimes even between cell towers.
VPN on demand features are on the iOS todo list. iOS supports the idea of making a VPN on demand for cellular or WiFi so it will be able to do what you want once that feature is merged.
Also, old appengine was built with nacl (remember that?) sandboxing. Anything that couldn’t be built under the nacl sandbox couldn’t run in app engine. Google realized this was a problem long ago but it takes time to rebuild your whole platform to eliminate such a fundamental dependency. That may have taken most of their focus, leaving little for other projects. and of course their new arch makes python 3 free so it’s difficult to have a parallel engineering effort that will be rapidly deprecated.