The standard does not specify plaintext. It says the client may use encryption.

Even doing unauthenticated TLS is better than what they do now, because the current situation allows for full passive monitoring.

The problem with 'may' is that a network intermediary might block TLS connections to ocsp.apple.com knowing it would fall back to plaintext.

Apple could encrypt the payload though, using the Apple public key, which would solve the snooping by intermediaries problem.

A network intermediary blocking or altering the TLS is an active attack. Plain HTTP is also vulnerable to that, so unauthenticated TLS is no worse than the current situation.

TLS encrypts the payload just fine if you want that. That’s what TLS is for.

PS: You don’t encrypt something to someone else using your own public key.

I'm talking about when they block just the ocsp host TLS port. Heaps of places whitelist https for particular sites, and inspect the content to prevent TLS. Appliances that block TLS via packet inspection are dime a dozen. But the query/response fields can be an opaque encrypted blob and it would get through. Every Apple device obviously has the Apple pub key, and hence they can send encrypted messages back to Apple without needing any further PKI.

Wouldn't an anonymity scheme such as [1] work in this context? Send only part of the hash of the app's certificate, and have the server send you all possible revoked certificates?

[1]: https://blog.cloudflare.com/validating-leaked-passwords-with...

As the set of certificates is bounded and known by apple, they can also adopt crlite and just push all CRLs they have to all users, using CRLite.

https://github.com/mozilla/crlite

I assumed there were too many revoked certificates for something like this to be viable, but I'm not surprised it is.

You probably can't update the whole list that often though, compared to Apple's current OCSP revalidate time of 5 min. [edit: seems "delta patches" are supported by crlite so maybe that can work too]

> I assumed there were too many revoked certificates for something like this to be viable, but I'm not surprised it is.

Given that Apple currently doesn't even encrypt the requests during transit, I think they just didn't pay much attention to the problem, which I think the main reason is why they haven't adopted it yet. As for the number of revoked certificates, I'm not sure it's larger than the number of revoked TLS certificates, given that there are way more websites out there than there are registered apple developers.

This is pretty much how chrome's safe browsing feature works for screening URLs without leaking the full details.

There is no valid reason that the full information needs to be sent to the server to implement this kind of protection IMO

Why is Apple limited bu Open Standards? It's not like any other servers are going to be receiving these messages.