4 ms·

HP to Apple: "Please revoke this certificate" Apple: "Okay done" Lapcatsoftware: "Apple is to blame for revoking this certificate" How is Apple supposed to k

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.

saagarjha 6y ago
Why else should Apple even be involved in the revocation process?
- colejohnson66 6y ago
  Someone has to give you the revocation list, and consumers generally aren’t smart enough to know even what a revocation list is. On Windows, it’s Microsoft. On macOS, it’s Apple.
  - saagarjha 6y ago
    Apple's revocation policy gives you no control over the revocation–you ask them to revoke things for you by contacting them, and then they decide whether this seems like a valid request, then they grant it for you. This is not how revocation usually works, so if so, why is Apple not vetting requests when they are placing themselves into the process?
    - X-Istence 6y ago
      That's the same way a CA works (except with a bit of automation instead of emailing someone). I go to the CA that issued my cert and say "I'd like to revoke this" (whether that is an API call or an email), they then publish the cert into their certificate revocation list. Now, Apple could deny a request, but they are under no obligation to do so, and I would argue that they shouldn't be making those judgement calls. As they did here, they get the email, they then publish the CRL, and wash their hands off it.
      - saagarjha 6y ago
        But that is exactly what they claim they are there to do. They should either just accept any request, or do a good job at denying incorrect revocations.
        X-Istence 6y ago
        Where do they claim to do that? Maybe there is no API for it because it happens so rarely that letting the Apple Security team push a few buttons is more cost effective.
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

saagarjha 6y ago

Why else should Apple even be involved in the revocation process?

colejohnson66 6y ago
Someone has to give you the revocation list, and consumers generally aren’t smart enough to know even what a revocation list is. On Windows, it’s Microsoft. On macOS, it’s Apple.
- saagarjha 6y ago
  Apple's revocation policy gives you no control over the revocation–you ask them to revoke things for you by contacting them, and then they decide whether this seems like a valid request, then they grant it for you. This is not how revocation usually works, so if so, why is Apple not vetting requests when they are placing themselves into the process?
  - X-Istence 6y ago
    That's the same way a CA works (except with a bit of automation instead of emailing someone). I go to the CA that issued my cert and say "I'd like to revoke this" (whether that is an API call or an email), they then publish the cert into their certificate revocation list. Now, Apple could deny a request, but they are under no obligation to do so, and I would argue that they shouldn't be making those judgement calls. As they did here, they get the email, they then publish the CRL, and wash their hands off it.
    - saagarjha 6y ago
      But that is exactly what they claim they are there to do. They should either just accept any request, or do a good job at denying incorrect revocations.
      - X-Istence 6y ago
        Where do they claim to do that? Maybe there is no API for it because it happens so rarely that letting the Apple Security team push a few buttons is more cost effective.

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