We would like to commend Mozilla and the CCADB members for this excellent work. It is a very strong first step in solving the rampant delayed revocation problem afflicting the WebPKI today. We expect this approach to be effective for these reasons:
· *It eliminates automatic or thoughtless delayed revocation.* By forcing both Subscribers and CAs to take on significant actions for each delayed revocation, it combats the common tendency we see to simply delay revocation for vast tranches or entire bodies of misissued certificates. · *It requires a true, individualized justification for each delayed revocation incident.* This will help the community understand the circumstances in which existing revocation timelines are legitimate societal problems and work on solutions. · *It has a strong deterrent effect for unnecessary delays.* By mandating documentation of reasons and restricting affected domains to 90-day certificates in the future, both Subscribers and CAs are motivated to hold back delays to only those cases where they are truly warranted. · *It still allows for delay in legitimate emergency cases.* There does exist a failsafe for the very rare occasion where a delayed revocation is truly warranted. · *It mitigates risk for non-agile environments.* Restricting domains experiencing delayed revocation to shorter-lived certificates reduces the overall risk these non-agile environments bring to the WebPKI. · *It encourages repair of the root problem.* Subscribers reduced to maximum 90-day term will be strongly motivated to adopt agile processes or move to private-root PKI solutions. As Subscribers become aware of this possibility, they will be motivated to prepare in advance for revocation events to avoid this eventuality. We wholeheartedly endorse this plan while recognizing that an additional level of detail remains to be worked out. To that effect, we have a few comments. The plan as written restricts certificates to 90-days for affected domains regardless of issuing CA. As a mitigating measure, this makes sense. It prevents Subscribers from simply hopping to another CA to avoid solving the core agility problem. *The suggested affected domains list managed by CCADB will be essential *to this program working correctly. A “90-day linter” would be valuable in aiding CA compliance with this requirement. If this part of the proposal becomes enforced policy, Sectigo is very interested in creating this linter and also plugging it into pkimetal. We believe this program strongly motivates Subscribers to become more agile with critical systems and to consider more seriously before demanding revocation delays. As such *public education of the new rules will strongly affect success*. We will encourage both CAs and browsers to assist in communicating these new rules clearly and broadly. *We notice that there is no end date for the 90-day certificate limit*. We agree with this decision, as it seems likely that the entire ecosystem will move to this timeline in the fairly near future anyway. We will point out that the deterrent and mitigating effects of this limit are eliminated once the maximum term for all public TLS certificates drops to 90-days. Once that happens, CCADB may want to consider a shorter limit for delrev domains (30 days?) to reinstate these benefits. Regarding which domains should be restricted to 90-days, as Matt also comments, we believe it would be essential to *restrict the base, registrable domain and all subdomains* under this policy. Doing otherwise would allow subscribers to get around this restriction through sub-domain hopping. While this could also be circumvented by registrable domain hopping, obviously that is considerably more difficult and comes with its own consequences. In conversation another CA suggested that we need to deal with the issue of *change of domain ownership*. Our first-blush reaction is that the shortened maximum term should remain even when a domain changes hands. This is mostly for practical reasons. It prevents Subscribers from shifting domains between their own companies or other such shenanigans. It prevents M&A activity from wiping clean domains that should still be restricted to 90-days. And it removes the need to create an entire mechanism for tracking ownership changes and marrying them back to maximum term. We hope a mechanism could exist to make the maximum allowed term of a domain *generally available knowledge*. That way potential buyers of domains or companies have the opportunity to account for that information before purchasing. *There does exist the possibility of a delayed revocation that is unintentional by both the CA and the Subscriber*. This could owe itself to a software bug or procedural error made purely in good faith. Under these circumstances there is no agility/criticality risk indicated for the domains in question. CCADB should consider what is required here. Clearly there will be no request from the Subscriber, and the CA’s explanation will be the same for all domains, which will be the error that led to the delay. Though such a thing is very rare, it is possible. Under these circumstances limiting affected domains to 90 days might be unnecessarily hard on Subscribers through no fault of their own. We are inclined to say in the case of a truly accidental revocation delay that this limit not be placed. Of course, this does open a potential loophole for bad-faith declarations from CAs that a revocation delay was motivated by an unwitting error. We expect that public scrutiny and reputational damage to the CA will be sufficient demotivators to prevent this kind of deceit and suggest there be a different set of requirements for unintended revocation delay. The CA should still be expected to report and explain the problem and to provide credible action items to prevent repeat of this error, just as with any other bug. On Thursday, September 19, 2024 at 5:53:30 PM UTC-4 Ben Wilson wrote: > Hi folks, > > We have discussed delayed revocation a bit internally and wanted to come > back to the community with some thoughts. > > We agree that expanding beyond the existing revocation timelines (24 hours > / 5 days) is undesirable. While we think some exceptional delayed > revocations are necessary as a current practicality, we do want to > eventually sunset this policy. To that end, we’d like to refine our > existing policy so that it is more effective and equitable during the > interim. > > We’re skeptical about proposals to pre-identify domains that will require > delayed revocation. We expect that many sites might ask for such > exceptions, and an extensive amount of deliberation would be required in > order to process these requests. Worse, in practice, doubtless some sites > impacted in a revocation event would not have followed the procedure, and > CAs would still be left with a last-minute decision about whether a > revocation will inflict substantial harm. > > Instead, we would like to seek the community's feedback on the following > two proposals: > > 1. > > Clarification of existing requirements > We would be more explicit about what would be required for delayed > revocation. Some ideas include: > 1. > > Explicitly clarifying that CAs must revoke certificates by default, > that any delayed revocation must be the result of an explicit request > by > the subscriber, containing the necessary information, and meeting the > requirements under such interim policy; > 2. > > That subscriber requests contain a clear claim or explanation about > the critical nature of the system and why timely revocation is not > possible > (more detailed requirements to be discussed); > 3. > > That the requests are signed by a company officer, or similar legal > representative, stating that the information in the request is accurate > to > the best of their knowledge; > 4. > > That the information contained in the subscriber’s request be > accurate to the CA’s understanding (e.g. not materially contradicted by > other facts known to the CA); > 5. > > That each granted request be published for the community (and > Mozilla) to scrutinize (allowing CAs to redact PII prior to > publication); > and > 6. > > That CAs be required to produce summary statistics in their reports > (alongside the individual granted requests) detailing how many requests > were received, how many were well-formed, how many were granted, etc. > > 2. > > Consequences of Delayed Revocation > We believe that if a domain hosts critical infrastructure that cannot > tolerate timely revocation, then it is deeply damaging to the web PKI. In > order to help these domains transition to effective certificate management > practices and automated tooling, we propose that domains that are granted > delayed revocation must then be limited to shorter-lifetime certificates > as > a consequence of such decision. This also ensures that future revocations > impacting such domains have much less impact. > > Concretely, the domains accepted for delayed revocation by a CA are > already public. If this proposal were to be adopted, root programs would > manage a shared list of such domains (e.g. via the CCADB) and require CAs > to limit the lifetimes of certificates issued to these domains (e.g. to 90 > days). > > We stress that both of these proposals are presented for early feedback, > and we look forward to the community’s thoughts on whether they are likely > to be suitable and effective, and how they might be improved. We would also > look to align these policies across the root programs in order to provide > clarity for the entire community. > > Thanks and best wishes, > > Ben > -- 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/d9d167f5-59b7-48ed-8558-9acbfa7fa685n%40mozilla.org.
