I’ve been thinking a lot about the first question, ever since I noticed how many of the certificates I sampled in lists of certificates for delayed revocation incidents included clear markers of not being a production environment. It was: dev, test, preprod, uat. It felt like a majority of them did, which makes sense if using webPKI for such environments is commonplace. I would have thought that more organizations used a private CA for these scenarios, but apparently not.
I think that requiring the reasons for delayed revocation, the risk for significant harm or internet outages, to be more closely tied to the systems is a good idea. But at the same time I think that it’s important to consider priorities and how they might be reversed in a security scenario compared to mississuance. If there is a security issue then delayed revocation of certificates protecting critical infrastructure could risk greater harm than just revoking. To incentivize prompt action for the production environments delaying revocation for non-production environments could give organizations a chance to focus without having to worry about non-critical hosts. In case of mississuance it could be better to allow an organization to delay revocation of their production environments so that they can verify that their reissued certificates work using their test environments. I also reacted to how many of the certificates were for domains that did not appear to have public DNS entries. And I’ve noticed some reluctance to reveal more detailed information about why a system is critical with references to security. I think that if the claim is made that: Yes this host is part of critical infrastructure, no it is not publicly available, and no we won't tell you what it does. Then the only proper answer is to hand them instructions to set up their own private CA. But that is a separate issue I guess. Br Zacharias On Wed, 26 Jun 2024 at 20:03, Mike Shaver <mike.sha...@gmail.com> wrote: > I have two questions about the Mozilla expectations for CAs who have > delayed revocation beyond the BR limits. > > For reference: > https://wiki.mozilla.org/CA/Responding_To_An_Incident#Revocation > > My first question concerns the requirements for detail about Subscriber > requests for delayed revocation, which are currently: > > - The decision and rationale for delaying revocation will be disclosed > in the form of a preliminary incident report immediately; preferably before > the BR-mandated revocation deadline. The rationale must include detailed > and substantiated explanations for why the situation is exceptional. > Responses similar to “we do not deem this non-compliant certificate to be a > security risk” are not acceptable. When revocation is delayed at the > request of specific Subscribers, the rationale must be provided on a > per-Subscriber basis. > > Question: should this not require per-certificate detail? A subscriber may > have certificates deployed in some systems that can't tolerate prompt > revocation, but that shouldn't prevent revocation of other certificates on > systems of lesser criticality. The report could group certificates that are > all part of a given critical system, for ease and brevity, but I think we > shouldn't give the impression that the Subscriber is the scope of the > decision to delay revocation, rather than the individual certificates. > > My second question concerns the expectation that the CA work with their > auditor and the root programs: > > - Your CA will work with your auditor (and supervisory body, as > appropriate) and the Root Store(s) that your CA participates in to ensure > your analysis of the risk and plan of remediation is acceptable. > > Question: is the expectation that the CA consults with the auditor and > root programs as part of making the decision to delay, or is it instead > meant to be a post-hoc consultation to get feedback on the risk analysis > and remediation plan that the CA established independently for the > incident? If it's the former, then I think that language should be changed > to make that explicit. If it's the latter, then I think it should be > explicit that the analysis and feedback be posted in the incident bug, so > that other CAs and root community members can learn from the process as > well. > > If there is agreement on these being worth considering, I'll open > appropriate github issues to discuss the details and make an actual > decision. > > Thanks, > > Mike > > -- > You received this message because you are subscribed to the Google Groups " > dev-security-policy@mozilla.org" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to dev-security-policy+unsubscr...@mozilla.org. > To view this discussion on the web visit > https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZqt8w5Em8nZc78ML4yQgcPNhBzAoUZjW71vzaa5_JvYb2g%40mail.gmail.com > <https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CADQzZqt8w5Em8nZc78ML4yQgcPNhBzAoUZjW71vzaa5_JvYb2g%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "dev-security-policy@mozilla.org" group. To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-policy+unsubscr...@mozilla.org. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CAKDW-UeRhPHP2VhN_jPGO_tZGTOqStoYSEmauvOOd%3DvTXJvSyw%40mail.gmail.com.
