Apple is not to blame for HP requesting the certificate be revoked, not even apportioned. HP is the sole requestor and the sole entity responsible for the cert being revoked.
This is what everyone misunderstands. The Developer ID code signing program is not analogous to web certs. The usage of these certs is entirely different.
Apps installed on a user's Mac are expected to run indefinitely, essentially forever. Developer ID signing certs do expire, but expiration only affects their ability to sign new app versions, it doesn't prevent old versions signed with the cert from running. The expired cert is still considered valid when you launch the app on a Mac.
When you connect to foo.com on the web, the server can use any valid cert. Certs get replaced quite frequently, often yearly. If you put a new cert on the server and revoke the old one, it doesn't necessarily harm web users, because they can make new connections with the new cert. But if a Developer ID cert is revoked, then macOS immediately (on OCSP check) prevents any app ever signed with that cert from launching, and calls it "malware". (The main purpose of Developer ID is to stop the spread of malware.) Even if the app has been installed on the user's machine for a long time, the app will no longer run. Revoking a Developer ID cert is a remote kill switch for Mac apps. This is why revocation of Developer ID certs is so destructive, and is almost always reserved only for malware.
The analogy with web CAs simply does not hold here.
Until this HP case, I've never heard of a 3rd party developer requesting that a Developer ID cert be revoked. All cases I've heard of are when Apple revokes the cert of a malware writer, which obviously the malware writer did not request.
A remote kill switch for Mac apps is extremely destructive, which is why only Apple has the power to revoke the Developer ID certs, which they should only do for a very good reason, such as malware.
It's also important to note that Developer ID is a requirement that Apple imposed on third party developers, purportedly for security purposes. We developers never wanted this, but we had no choice. Again, none of this is really under our control, it's Apple's program, and Apple is the sole CA for Mac app certs.
The brilliant thing about pki is that certificate usage is based on its cryptographic purpose. It doesn’t care about the application itself.
It’s actually a good thing that Apple doesn’t just verify the certs on install. The kill switch serves a vital security purpose.
But if a malware is signed and installed to a computer, revoke it can prevent further running.
If a web cert gets revoked a browser won't accept it when making a connection to a domain/server anymore even if they previously did (unless you make it). If an app signing cert gets revoked the OS won't run a binary signed with it anymore even if it previously did (unless you make it). Sounds similar enough to me, minus expiry handling.
Revocation is indeed extremely destructive and should only used by Apple on their own accord against malware but I don't see why a dev themselves shouldn't be able to revoke their own cert without having to go back and forth with the Apple security/support team to have to try to convince them that the issue is severe enough.
The main and basically almost only reason where I see developer side revocation be used is if their keys or account have been (possibly) compromised and therefore there's a chance of it being used for malware. Time can be of big importance in a situation like that too. As a user I absolutely want Apple to revoke certs when requested by the dev themselves without triple verifying if they are really totally actually absolutely sure. I consider the upsides of that to outway the downsides.
While a binary from a dev that has been installed for a long time will be less likely to be malware but not enough to be exempt from that.
Users that dislike OSCP can disable it fully on their side if they want or locally sign anything specific they do trust. Devs didn't ask for it but having developer IDs and application singing seems like a pretty sensible thing to me in an end user OS used by the average consumer.
The difference is that you can just get a new web cert, install it on the server, and you're good to go for https. On the other hand, getting a new Developer ID cert doesn't help at all to make the app start running again. You can sign new versions of the app with the new cert, but the installed versions of the app signed with the revoked cert are still dead as a doornail, which is no good at all for your existing user base.
> The main and basically almost only reason where I see developer side revocation be used is if their keys or account have been (possibly) compromised and therefore there's a chance of it being used for malware.
It's not clear that this ever happens. I discussed the case of Panic in the blog post. Their private key was possibly compromised, but Apple did not revoke their cert! The old cert is still valid, and so are the old versions of their apps. Apple apparently has a more limited way of disabling apps, based on the secure timestamp of the code signature.