4 ms·

> Software developers have the remote kill switch as well, and they used it this time. How so? They can't unilaterally revoke a Developer ID cert, they can onl

by _qulr 6y ago

> Software developers have the remote kill switch as well, and they used it this time. How so? They can't unilaterally revoke a Developer ID cert, they can only request that Apple revoke it. > Apple did nothing wrong, unless you’re of the opinion that Apple should be auditing other company’s internal policies and controls. This is missing the point of Developer ID. It's a program created by Apple and imposed as a requirement on Mac developers. The purpose of the Developer ID cert is to prevent malware. That's why it has a remote kill switch, to stop malware from running. The purpose was not to give Mac developers a remote kill switch to use however they please. Why in the world would Apple do that? Developer ID is not an "internal policy" for third party developers. There's nothing to audit. Developer ID is Apple's program, designed for Apple's purposes, and Apple makes the decision whether or not to revoke the certs. Almost all known Developer ID certificate revocations are not the result of the developer's own request but rather the result of Apple discovering malware in the wild and revoking the certs of the malware authors.

olliej 6y ago
> How so? They can't unilaterally revoke a Developer ID cert, they can only request that Apple revoke it. That is literally how revocation works. There is no magic "make this key no longer work" function. Revocation of a cert means telling the CA to revoke the cert. It is no different when the CA is Apple, than if it were Thawte, or Google, or LetsEncrypt. Revocation means telling the CA to add your certificate to the list they publish of no longer valid certificates. Managing your certs if absolutely the responsibility of the developer. It is no different from any other cert - TLS certs, S/MIME, etc are all the same. The only difference is the usage flags included in the cert. > Almost all known Developer ID certificate revocations are not the result of the developer's own request but rather the result of Apple discovering malware in the wild and revoking the certs of the malware authors. That is, apple has found evidence of key compromise, and so revoked the cert. For WebPKI CAs there is a hard requirement that the moment they receive any evidence of a key being compromised they are required to revoke within 24 hours, or risk penalization. Again, Apple is acting no differently from any other CA.
- _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

by _qulr 6y ago

olliej 6y ago

> How so? They can't unilaterally revoke a Developer ID cert, they can only request that Apple revoke it. That is literally how revocation works. There is no magic "make this key no longer work" function. Revocation of a cert means telling the CA to revoke the cert. It is no different when the CA is Apple, than if it were Thawte, or Google, or LetsEncrypt. Revocation means telling the CA to add your certificate to the list they publish of no longer valid certificates. Managing your certs if absolutely the responsibility of the developer. It is no different from any other cert - TLS certs, S/MIME, etc are all the same. The only difference is the usage flags included in the cert. > Almost all known Developer ID certificate revocations are not the result of the developer's own request but rather the result of Apple discovering malware in the wild and revoking the certs of the malware authors. That is, apple has found evidence of key compromise, and so revoked the cert. For WebPKI CAs there is a hard requirement that the moment they receive any evidence of a key being compromised they are required to revoke within 24 hours, or risk penalization. Again, Apple is acting no differently from any other CA.

_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