Apple: Developer ID Certificate Revocation (OCSP)
lapcatsoftware.com
Apple: Developer ID Certificate Revocation (OCSP)
1–10 of 35 posts
Re: Apple: Developer ID Certificate Revocation (OCSP)
#2HP 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.
Re: Apple: Developer ID Certificate Revocation (OCSP)
#3HP 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.
Why else should Apple even be involved in the revocation process?
Re: Apple: Developer ID Certificate Revocation (OCSP)
#4HP 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.
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.)
Re: Apple: Developer ID Certificate Revocation (OCSP)
#5HP 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.
Why else should Apple even be involved in the revocation process?
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.
Re: Apple: Developer ID Certificate Revocation (OCSP)
#6Earlier quoted context omitted.
Why else should Apple even be involved in the revocation process?
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.
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?
Re: Apple: Developer ID Certificate Revocation (OCSP)
#7Earlier quoted context omitted.
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.
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?
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.
Re: Apple: Developer ID Certificate Revocation (OCSP)
#8HP 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.
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 f…
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?
Re: Apple: Developer ID Certificate Revocation (OCSP)
#9HP 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.
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 f…
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.
Re: Apple: Developer ID Certificate Revocation (OCSP)
#10Earlier quoted context omitted.
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 f…
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.
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.