[thristian]

The problem with revoking certificates for websites is: how do you know when to check if a certificate is black-listed? You can't download a list of blacklisted certificates, because who would keep track of them all, and how huge would the database be? Some certificates include the URL of a 'revocation list' which allows the browser to check if that certificate has been revoked, but if the browser checks each certificate that it sees then suddenly Verisign's revocation list server becomes a single-point-of-failure for half the Internet, and that's no good either.

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.

[DaveMebs]

What? Your first paragraph concludes that if everyone is checking Verisign's CRL they become the single point of failure for half the internet, yet you conclude the a better solution is to only check Apple's certs, making them the ONLY point of failure? I don't think you really understand how digital certificates work.

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.

[count]

Just a nitpick, but OCSPs is not the plural of OCSP, and you don't 'download' it the way a CRL works. OCSP stands for 'Online' Certificate Status Protocol, and is a query/response protocol, that functions much like the DNS - you don't download the whole deal, you ask about the validity of a specific, single record, and get a 'yes'/'no' response.

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.

[pyre]

The real problem with revocation lists for websites is that there is no secure channel to transfer them over. You can't transfer them over SSL because you don't know which certs you shouldn't trust until you get the list.

If someone is alreay man-in-the-middling you with a cert you trust, they can easily filter the revocation lists that you download.

[chalst]

But you can know whether a CRL is valid, provided Apple's own CA hasn't been compromised. If Apple were to issue a complete CRL every 6 hours or so, then man-in-the-middle filtering won't work since clients can simply not trust any new signatures until they have seen the current CRL.

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.

[pyre]

Also...

  > provided Apple's own CA hasn't been compromised

We've been seeing this happen a lot lately, so that's a big assumption.

[pyre]

I was mostly commenting on the first paragraph in relation to the web, not specifically about Apple using certificates.