from Hacker News

Apple: Developer ID Certificate Revocation (OCSP)

by milen on 11/12/20, 11:14 PM with 34 comments

  • by X-Istence on 11/12/20, 11:48 PM

    HP to Apple: "Please revoke this certificate"

    Apple: "Okay done"

    Lapcatsoftware: "Apple is to blame for revoking this certificate"

    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.

  • by meibo on 11/13/20, 12:32 AM

      The check consists of an HTTP GET request (port 80, unencrypted!) to ocsp.apple.com
    Am I missing something? Is this still the case?

    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.

  • by donor20 on 11/13/20, 12:36 AM

    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?

    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.

    Now we are told that blame "MUST" be apportioned? "HP and Apple failed in their responsibility"

    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.

    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.

    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.

  • by tgsovlerkhgsel on 11/13/20, 9:09 AM

    > 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.

    Interesting. This means OSX leaks which apps you run unencrypted on the network.

  • by SAI_Peregrinus on 11/13/20, 2:57 AM

    A certificate revocation request signed by the private key is proof of private key compromise.

    Anyone issuing such a revocation due to knowledge of compromise of the key is notifying the issuing authority of the compromise.

    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.

    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.

    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.

  • by heavensgateboy on 11/13/20, 1:57 AM

    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.