4 ms·

> It is no different from any other cert - TLS certs, S/MIME, etc are all the same. No, this is where the argument is fatally flawed. The usage of code signing

by _qulr 6y ago

> It is no different from any other cert - TLS certs, S/MIME, etc are all the same. No, this is where the argument is fatally flawed. The usage of code signing certs and web certs is completely different. At any time, you can put a new web cert on your server, and web traffic can continue as if nothing happened. Revoking a web cert that's no longer in active use does not affect current web traffic. On the other hand, that's not the way it works with code signing. Users download and install signed software. That software is expected to run indefinitely, essentially forever as long as the software itself works. The expiration date for code signing certs only affects the ability to sign new software, it does not affect the ability of old signed software to continue running. Code signing certs expire, but the signed software does not. However, when a code signing cert is revoked, it immediately (on the next OCSP check) kills the old, installed software. That's a total disaster, unless that installed software happens to be malware. This is why revoking a code signing cert is so much worse than revoking a web cert. > Revocation means telling the CA to add your certificate to the list they publish of no longer valid certificates. To be pedantic, Developer ID doesn't actually use a CRL, only OCSP: https://images.apple.com/certificateauthority/pdf/Apple_Developer_ID_CPS_v3.0.pdf https://images.apple.com/certificateauthority/pdf/Apple_Deve...

olliej 6y ago
> existing software borked Yes by design just like your existing services are borked until you set up new certs. Where HP screwed up was that they didn’t re-sign their binaries, so people would (correctly) go and download the drivers again and get the same failure. Again, it is not apples job to work out if you really wanted to revoke a cert, or you just screwed up. How are they meant to make that determination? Let’s put it another way, say someone requests a revocation issue to malicious actor or some such. And Apple then futzes around going back and forth through email to make sure revocation is intended. The headline would be “Apple tried to stop me revoking my signing certificate” > CRL vs OCSP OCSP is fed from a list the CA manages. Whether you’re downloading a list of revocations ahead of time or getting individual responses is moot.
- _qulr 6y ago
  > it is not apples job to work out if you really wanted to revoke a cert, or you just screwed up. It is literally Apple's job. From the Certification Practice Statement: "The Subscriber may initiate a revocation request by sending an email to product-security@apple.com. The request for revocation will then be evaluated by Apple." > Let’s put it another way, say someone requests a revocation issue to malicious actor There's no evidence that this is what happened with HP. There's one known case where a Developer ID cert may have been compromised: https://panic.com/blog/stolen-source-code/ https://panic.com/blog/stolen-source-code/ Apple worked very closely with the developer, they didn't just receive an email and reflexively act without thinking. Moreover, in this case, Apple did not actually revoke the cert! Old versions of Panic apps signed with the cert still run fine. Apparently Apple has a way to use the secure timestamp of the code signature to selectively disable apps signed after a certain date. Again, all non-accidental Developer ID cert revocations that I'm aware of were owned by malware developers, and revoked on Apple's initiation. I've never heard of a case, until HP, where the developer requested the revocation of their own Developer ID cert. And we would know if a legitimate developer's cert was revoked, because their software would stop working, just as it did with HP, and with the accidental Charlie Monroe revocation (which was entirely Apple's fault). Perhaps there are cases where a cert was never used, and then revoked. But Apple needs to be extremely careful about these cases, because we've seen the terrible consequences when a cert is mistakenly revoked. And there's certainly no rush to revoke an unused cert.

by _qulr 6y ago

olliej 6y ago

> existing software borked Yes by design just like your existing services are borked until you set up new certs. Where HP screwed up was that they didn’t re-sign their binaries, so people would (correctly) go and download the drivers again and get the same failure. Again, it is not apples job to work out if you really wanted to revoke a cert, or you just screwed up. How are they meant to make that determination? Let’s put it another way, say someone requests a revocation issue to malicious actor or some such. And Apple then futzes around going back and forth through email to make sure revocation is intended. The headline would be “Apple tried to stop me revoking my signing certificate” > CRL vs OCSP OCSP is fed from a list the CA manages. Whether you’re downloading a list of revocations ahead of time or getting individual responses is moot.

_qulr 6y ago
> it is not apples job to work out if you really wanted to revoke a cert, or you just screwed up. It is literally Apple's job. From the Certification Practice Statement: "The Subscriber may initiate a revocation request by sending an email to product-security@apple.com. The request for revocation will then be evaluated by Apple." > Let’s put it another way, say someone requests a revocation issue to malicious actor There's no evidence that this is what happened with HP. There's one known case where a Developer ID cert may have been compromised: https://panic.com/blog/stolen-source-code/ https://panic.com/blog/stolen-source-code/ Apple worked very closely with the developer, they didn't just receive an email and reflexively act without thinking. Moreover, in this case, Apple did not actually revoke the cert! Old versions of Panic apps signed with the cert still run fine. Apparently Apple has a way to use the secure timestamp of the code signature to selectively disable apps signed after a certain date. Again, all non-accidental Developer ID cert revocations that I'm aware of were owned by malware developers, and revoked on Apple's initiation. I've never heard of a case, until HP, where the developer requested the revocation of their own Developer ID cert. And we would know if a legitimate developer's cert was revoked, because their software would stop working, just as it did with HP, and with the accidental Charlie Monroe revocation (which was entirely Apple's fault). Perhaps there are cases where a cert was never used, and then revoked. But Apple needs to be extremely careful about these cases, because we've seen the terrible consequences when a cert is mistakenly revoked. And there's certainly no rush to revoke an unused cert.