Many thanks to all of you for your continued input. I have updated the first sentence of the second paragraph of the draft <https://docs.google.com/document/d/1ESakR4MiwyENyuLefyH2wG8rYbtnmG1xeSYvDNpS-EI/edit?usp=sharing> to the following, and will continue to appreciate your help with the wording. My intent is to provide some protection to the website operator so that a CA cannot revoke their certificate for non-critical reasons without letting them know and take action first. The responsibility may be on the website operator to have automation to check for that information, as opposed to sending notifications via email. So I will continue to appreciate your help with the wording.
"When a certificate revocation is not due to key compromise and is not initiated by the certificate subscriber, the CA MUST make the information regarding its intent to revoke an end-entity SSL certificate available to the certificate subscriber at least 24 hours before revoking the certificate ." I am particularly interested in having more discussion about the following from Rob: On Thursday, December 30, 2021 at 8:37:07 AM UTC-8 [email protected] wrote: > I can understand why the keyCompromise and cACompromise reason codes are > of interest, but I'm struggling to see why Mozilla might be interested in > differentiating between privilegeWithdrawn, cessationOfOperation, and > superseded. Why are any of these 3 reason codes more useful than having no > reason code at all? What use cases would be enabled if CAs were to use > these 3 reason codes as you propose? > > FWIW, at the moment my counter-proposal would be roughly along these lines > (for leaf certificate revocations): > - CAs MUST use keyCompromise for (and only for) proven or suspected key > compromise. > - CAs MUST revoke immediately in the case of proven key compromise. > - CAs SHOULD NOT use other reason codes. > - Beyond that, follow the BRs. > > How do you all think that browsers should enforce end-entity TLS certificate revocations? e.g. Should ALL end-entity TLS certificate revocations be enforced via non-over-rideable errors? Or should the user be able to continue past the error to the website when the revocation is for something other than key compromise? Should a non-over-rideable error be presented for end-entity TLS certificates that are revoked for privilegeWithdrawn? Should a non-over-rideable error be presented for end-entity TLS certificates that are revoked for cessationOfOperation? Should a non-over-rideable error be presented for end-entity TLS certificates that are revoked for superseded? We all know that if user gets a non-over-rideable error in one browser they will try again with another browser, so enforcing any revocations in only one browser will not be very effective in protecting the user. So I am looking for a solution that may be more broad than Firefox, with the hopes that other browsers will be able to eventually use the revocation reasons for end-entity TLS certificates too. I am under the impression that other browsers will not enforce ALL end-entity TLS certificate revocations with hard fail, and that the rules about the use of certain revocation codes must be in place and in use before they will consider automatically enforcing via hard fail any end-entity TLS certificate revocations. Thanks, Kathleen -- You received this message because you are subscribed to the Google Groups "[email protected]" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/fb3a0850-cd60-4c53-8c72-095ad4ade8b7n%40mozilla.org.
