3 ms·

This is in response to the issue last week where slowness of Apple's OCSP responders caused hangs in apps launching. It was a bad look for privacy-conscious App

This is in response to the issue last week where slowness of Apple's OCSP responders caused hangs in apps launching. It was a bad look for privacy-conscious Apple especially considering that basic OCSP queries are unencrypted HTTP requests. In my post (https://blog.cryptohack.org/macos-ocsp-disaster https://blog.cryptohack.org/macos-ocsp-disaster) I argued that OCSP was inherently a poor way to perform certificate revocation in this scenario, and that an approach based on Certificate Revocation Lists (CRLs) could be preferable. Regardless, it looks like Apple might be doubling down on OCSP but encrypting the requests, or possibly adding a new protocol altogether.

lifthrasiir 6y ago
> But it’s also fundamentally different since Apple has total control over its own chain of trust. Other certificate authorities are not allowed to issue valid certificates for code signing as all certificates must chain back up to Apple. To me this was the most curious part of the entire situation. The post briefly mentions CRLite and bloom filters; they rely on the list of all if not most valid certificates (which were impossible before CT) and it's understandable that they are not yet widely deployed. But Apple does surely know the list of all developer certificates and can simply publish a (probably compressed) list of serial IDs of revoked developer certificates that would be otherwise valid. I don't see a good reason to use big moving parts like OCSP here especially given the soft-fail behavior.