Signing certs for Mac software would be different because there is exactly one central signing authority (Apple), so batch-downloading a list of revoked certs is feasible - bundle them with your monthly security patch updates, for example.
Signing certs for Mac software would be different because there is exactly one central signing authority (Apple), so batch-downloading a list of revoked certs is feasible - bundle them with your monthly security patch updates, for example.
Downloading blacklists of certs is exactly what happens. They are called OCSPs and CRLs. The operating system is responsible for tracking these through a combination of caching and downloading new OCSPs/CRLs. The database does not grow too large, because CAs use certificate chains. The cert that is vouching for some website is not the cert in your trusted root store. Root store certs are kept under lock and key - these very rarely get compromised (this is what happened to DigiNotar and they are no longer in business - their certs were invalidated by everyone in the industry and they were filing bankruptcy less than a month later).
What does happen are leaf certs being compromised. When this occurs only that leaf and everything below it in the chain is revoked, so if you have enough certs in the chain you usually don't revoke many certs at a time. Generally speaking, the lower the cert in the chain the lower the trust level, which includes stuff like the cert not remaining valid for as long a period.
You can read about how Windows implements cert revocation here: http://technet.microsoft.com/en-us/library/ee619754%28WS.10%...
I'd assume Apple does something very similar.
OCSP is a privacy problem, as well as a bottleneck/performance problem for any large, non-organizational CA, such as Verisign and their compatriots. Every single SSL certificate must be checked at each handshake in order to make sure it hasn't be revoked in the past 'n' hours (there is some caching, which kind of defeats the purpose). This means that in practice, the CA's know who is visiting what sites, and that they must be online and active and responding in a timely fashion (like the DNS) before a browser will allow an HTTPS connection.
If someone is alreay man-in-the-middling you with a cert you trust, they can easily filter the revocation lists that you download.
So the man-in-the-middle attack can keep the client ignorant of the contents of the CRL, but can't trick the client into believing a revoked certificate has not been revoked.
SSL is a red herring here, since we care about authenticity, not privacy.
> provided Apple's own CA hasn't been compromised
We've been seeing this happen a lot lately, so that's a big assumption.