On 17/04/2020 14:22, Nick Lamb via dev-security-policy wrote:
GOOD means_at least_ the good CertStatus (also 0) in OCSP. We'll see why in a moment.
Fair enough. That's what I thought - so holding onto the last successful OCSP report you have, even if you get exception status codes thereafter is a good way forward. I think that's reasonable. I'm just less sure that you should be treating a well formed 'revoked' response as something which can be ignored until the current 'good' OCSP response expires. [Note my carefully chosen weasel words like 'well formed', which also entails stuff like proper timestamp checking etc, etc]. Ryan's writeup calls out the revoked situation under the heading of 'make sure it is something the client will accept' - if the client understands OCSP responses at all, it needs to understand revoked, surely?
But why? We are us, why would we want to announce that our certificate is revoked? What possible benefit could accrue to us from choosing to do this?
Because it places you (a good actor) in compliance with your subscriber agreement? Just as an example, some text in a few commonly used CA Subscriber Agreements have subscriber obligations like "cease all use of the Certificate and its Private Key upon expiration or revocation of the Certificate" or "Subscriber shall promptly cease using a Certificate and its associated Private Key" (under the section for revocation). Presumably failure to adhere to that agreement could place you in some contractual jeopardy?
So, following from your response, I think that, indeed - shutting down the site until a replacement key/cert is deployed would be the 'right' thing to do, rather than advertise a revoked response. The difference being that shutting down is (usually) a manual step, whereas stapling the most recent valid response from the CA (good or revoked) is probably an automated step.
Regards, Neil _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
