Dear Ben, Thanks a lot for your effort which is highly appreciated.
SwissSign would prefer option 2 (Consequences of Delayed Revocation) over option 1 as an interim policy change. The reason being that it has nudges the customer toward automation. However we believe that there are some customers who really struggle with automation and we believe it is important to get more insights into what exactly their problems are. Additionally, from a customer point of view (as well as the whole PKI community) it would be important to outline the final target state that such an interim policy change would work towards including the time frame of the final state. >From our previous delayed revocation, we know that: * public trust certificates are used where private PKIs may be better suited * customer internal approval processes take more time than a 24h/5d revocation timeline allows * certificate pinning is still used (although it is generally known that it's a bad idea) that requires update to applications * update of certificates in Apps that require re-publishing in App-Stores which may not be possible within the required timeline * customer awareness of their contractually agreed requirement to be able to deal with 24h/5d revocation is low All these are not problems that a CA alone can fix. All we can do is educate, support to the best of our abilities and revoke on time. Finally, we think that we should consider if TLS and S/MIME should be treated the same or not. To this, we currently don't have a position/preference. Kind regards Sandy Balzer / SwissSign team Von: 'Ben Wilson' via [email protected] <[email protected]> Gesendet: Donnerstag, 19. September 2024 23:53 An: [email protected] <[email protected]> Betreff: Proposal for an Interim Policy to Address Delayed Revocation 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: * 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; * 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); * 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; * 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); * That each granted request be published for the community (and Mozilla) to scrutinize (allowing CAs to redact PII prior to publication); and * 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. 1. 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]<mailto:[email protected]>" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]<mailto:[email protected]>. To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaYZWhgfs23hB-Z%3DgEQCybugPrP8W4MSdnX9Y-dyoMoarA%40mail.gmail.com<https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/CA%2B1gtaYZWhgfs23hB-Z%3DgEQCybugPrP8W4MSdnX9Y-dyoMoarA%40mail.gmail.com?utm_medium=email&utm_source=footer>. -- 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/ZRAP278MB02055186C3ADE6C1E2B1B22E86772%40ZRAP278MB0205.CHEP278.PROD.OUTLOOK.COM.
