4 ms·

Your quote of Lapcatsoftware is just wrong. It is not: > Apple is to blame for revoking this certificate. It is: > So blame must be apportioned to both compa

by jchw 6y ago

Your quote of Lapcatsoftware is just wrong. It is not: > Apple is to blame for revoking this certificate. It is: > So blame must be apportioned to both companies. ...because the revocation itself seems to have been an unjustified request. It seems the value-add of Apple having the sole ability to revoke certificates would be that they could avoid something like this. (That said, I do think this is still mostly HP's fault, but the article raises a point that is more valid than implied.)

abiogenesis 6y ago
What should be the proper process then? Should Apple reply to all revocation requests asking for a proof that the certificate has really been compromised? OCSP or CRL revocations are easy to revert, so why risk letting a compromised certificate to be used for an extended amount of time?
- jchw 6y ago
  Beats me. Apple could just give developers full discretion, which would lower the amount of time it takes to get a really compromised certificate even more. Presumably, there is some good reason to have manual discretion, otherwise, why have it?
- bentcorner 6y ago
  I agree that HP was careless here but IMO Apple should learn here that developers who ask for a cert revocation may not understand the consequences or the cases where this is necessary. I have no idea what the cert revocation workflow looks like, but providing cases where it should and shouldn't be used would be useful. It's still certainly possible that this falls squarely on HP and there's only so much you can do when someone is determined to blow their foot off.
- tgsovlerkhgsel 6y ago
  As far as I know, CRL revocations are considered irreversible if done with any reason except certificateHold.
X-Istence 6y ago
Replace Apple with any CA on the world wide web, if I go ask them to revoke a certificate, they should just do as I ask. Not try and second guess me. 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.
- jchw 6y ago
  Other CAs allow you to revoke certificates. For example, it can be done via the API with ACME. It is unclear why Apple doesn't delegate this ability entirely to developer discretion, but presumably this is the reasoning.
- _qulr 6y ago
  > Replace Apple with any CA on the world wide web 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.

by jchw 6y ago

abiogenesis 6y ago

What should be the proper process then? Should Apple reply to all revocation requests asking for a proof that the certificate has really been compromised? OCSP or CRL revocations are easy to revert, so why risk letting a compromised certificate to be used for an extended amount of time?

jchw 6y ago
Beats me. Apple could just give developers full discretion, which would lower the amount of time it takes to get a really compromised certificate even more. Presumably, there is some good reason to have manual discretion, otherwise, why have it?
bentcorner 6y ago
I agree that HP was careless here but IMO Apple should learn here that developers who ask for a cert revocation may not understand the consequences or the cases where this is necessary. I have no idea what the cert revocation workflow looks like, but providing cases where it should and shouldn't be used would be useful. It's still certainly possible that this falls squarely on HP and there's only so much you can do when someone is determined to blow their foot off.
tgsovlerkhgsel 6y ago
As far as I know, CRL revocations are considered irreversible if done with any reason except certificateHold.

X-Istence 6y ago

Replace Apple with any CA on the world wide web, if I go ask them to revoke a certificate, they should just do as I ask. Not try and second guess me. 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.

jchw 6y ago
Other CAs allow you to revoke certificates. For example, it can be done via the API with ACME. It is unclear why Apple doesn't delegate this ability entirely to developer discretion, but presumably this is the reasoning.
_qulr 6y ago
> Replace Apple with any CA on the world wide web 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.