HP to Apple: "Please revoke this certificate"<p>Apple: "Okay done"<p>Lapcatsoftware: "Apple is to blame for revoking this certificate"<p>How is Apple supposed to know that the certificate has not been compromised? When I ask my CA to revoke a certificate I don't have to explain why to them, they just do it. They are my consequences to bear.
<p><pre><code> The check consists of an HTTP GET request (port 80, unencrypted!) to ocsp.apple.com
</code></pre>
Am I missing something? Is this still the case?<p>Seems like an obvious privacy issue, to be able to identify if an user is launching apps from a certain developer just by doing very basic packet capture.
What the heck. You don't have to prove private key compromise for a CA to revoke a cert, you just ask them to revoke it. How in the world is this apple's fault?<p>As long as they authenticate the person requesting the revocation. In most CA's, this can be done by signing the request with the private key to prove control.<p>Now we are told that blame "MUST" be apportioned? "HP and Apple failed in their responsibility"<p>For all we know HP could have found a remote zero day exploit in their drivers, and was going to initiate a replacement effort or something.<p>The author also complains no CRL is available, but that's a good thing in these cases, if there is a mistake certificate status can be updated. So again, apple has an approach here that means it's not too hard to get folks printing again.<p>The author makes a case that a publisher can only revoke in the case of malware and key compromise. I can think of PLENTY of situations where revocation might make sense (and publisher may be still sued I'm sure) outside of that, for small teams and even for big teams.
> <i>The check consists of an HTTP GET request (port 80, unencrypted!) to ocsp.apple.com with a path that is both Base64 encoded and URL encoded.</i><p>Interesting. This means OSX leaks which apps you run unencrypted on the network.
A certificate revocation request signed by the private key <i>is</i> proof of private key compromise.<p>Anyone issuing such a revocation due to knowledge of compromise of the key is notifying the issuing authority of the compromise.<p>If a key is used for a purpose not listed as allowed in the certificate, it's compromised, even if the entity that misused the key is the original holder.<p>Anyone issuing such a revocation without authorization has the private key, and is using it for something they're not authorized to use it for. It's compromised by definition.<p>There's never a reason not to revoke a certificate when a valid revocation request is received. The key has been compromised, either by leaking or by misuse.
This entire thing is likely related to Apple’s engineered obsolescence cycle. They have already been busted intentionally causing issues on their platforms prior to the release of new products in order to drive sales. It’s a grey area legally and difficult to prove, but it’s essentially a form of racketeering.