<div dir="ltr"><div><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Dear Colleagues,</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"><br></span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">On behalf of Mozilla, Kathleen and I intend to update our policy soon to require that the validity period of TLS certificates be 398 days or less [1]. Regardless of whether this particular change is adopted as part of the Browser Alignment ballot, Mozilla intends to require it and implement code to enforce it. In preparation for this change, Mozilla’s May 2020 CA Communication [2] surveyed CAs about when they plan to limit TLS certificate validity periods to 398 days or less [3]. While many CAs indicated their dissatisfaction with the way in which the requirement has come about, all CAs indicated that they would reduce their TLS certificate validity period to 398 days or less by September 1, 2020. Therefore, we view this change as an appropriate part of the effort to align the BRs to root store policies.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">In regards to whether the CA/Browser Forum sets best practices, we believe that the Baseline Requirements are a collection of minimum requirements that CAs must adhere to, and that one of the benefits of the BRs is it enables there to be a common set of audit criteria, so that CAs can provide one set of audits annually to all of the browser root programs.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">In regards to whether there must be collective decision-making, Mozilla has and will continue to add requirements to Mozilla’s Root Store Policy as needed to keep Mozilla’s users safe. Changes to Mozilla’s Root Store Policy do not need to be done via consensus or collective decision-making and are not necessarily dependent on adoption into the BRs. Mozilla’s process for updating our root store policy involves public discussion, but ultimately Mozilla’s Root Store Policy Module Owner and Peers decide how and when the policy will be updated [4].</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">As Mozilla’s Root Store Policy says [5]:</span></p><ol style="margin-top:0px;margin-bottom:0px"><li dir="ltr" style="list-style-type:decimal;font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Section 2.3: In the event of inconsistency between Mozilla’s Root Store Policy requirements and the Baseline Requirements, Mozilla’s Root Store Policy takes precedence. </span></p></li><li dir="ltr" style="list-style-type:decimal;font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Section 7.1: We reserve the right to not include certificates from a particular CA in our root program. …  Mozilla is under no obligation to explain the reasoning behind any inclusion decision.</span></p></li><li dir="ltr" style="list-style-type:decimal;font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Section 7.1: CAs MUST provide evidence that their CA certificates have continually, from the time of creation, complied with the then-current Mozilla Root Store Policy and Baseline Requirements.</span></p></li><li dir="ltr" style="list-style-type:decimal;font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre"><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Section 7.3: Mozilla MAY, at its sole discretion, decide to disable (partially or fully) or remove a certificate at any time and for any reason.</span></p></li></ol><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">In summary, we agree with Ryan’s message that the BRs represent the collective minimum requirements of Root Programs and that Root Programs set their own policies. We think that it is now reasonable to consider the change to reduce the TLS certificate validity period to a maximum of 398 days as part of aligning the BRs with root store policies, so we think that this change should remain in the Browser Alignment Ballot (SC31). We would like to see the Browser Alignment ballot adopted, but are ready to add all of the changes in the ballot directly to Mozilla’s Root Store Policy as needed.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Regards,</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Ben Wilson</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">Mozilla CA Program Manager</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">References:</span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">[1] </span><a href="https://github.com/mozilla/pkipolicy/issues/204" style="text-decoration:none"><span style="font-size:11pt;font-family:Arial;color:rgb(17,85,204);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:underline;vertical-align:baseline;white-space:pre-wrap">https://github.com/mozilla/pkipolicy/issues/204</span></a></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">[2] </span><a href="https://wiki.mozilla.org/CA/Communications#May_2020_CA_Communication" style="text-decoration:none"><span style="font-size:11pt;font-family:Arial;color:rgb(17,85,204);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:underline;vertical-align:baseline;white-space:pre-wrap">https://wiki.mozilla.org/CA/Communications#May_2020_CA_Communication</span></a></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">[3] </span><a href="https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00105,Q00106,Q00107" style="text-decoration:none"><span style="font-size:11pt;font-family:Arial;color:rgb(17,85,204);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:underline;vertical-align:baseline;white-space:pre-wrap">https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00105,Q00106,Q00107</span></a><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap"> </span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">[4] </span><a href="https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#12-policy-ownership" style="text-decoration:none"><span style="font-size:11pt;font-family:Arial;color:rgb(17,85,204);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:underline;vertical-align:baseline;white-space:pre-wrap">https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#12-policy-ownership</span></a></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">[5] </span><a href="https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy" style="text-decoration:none"><span style="font-size:11pt;font-family:Arial;color:rgb(17,85,204);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:underline;vertical-align:baseline;white-space:pre-wrap">https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy</span></a></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-size:11pt;font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:none;vertical-align:baseline;white-space:pre-wrap">[6] </span><a href="https://github.com/mozilla/pkipolicy/issues?q=is%3Aissue+is%3Aopen+label%3A2.7.1" style="text-decoration:none"><span style="font-size:11pt;font-family:Arial;color:rgb(17,85,204);background-color:transparent;font-weight:400;font-style:normal;font-variant:normal;text-decoration:underline;vertical-align:baseline;white-space:pre-wrap">https://github.com/mozilla/pkipolicy/issues?q=is%3Aissue+is%3Aopen+label%3A2.7.1</span></a></p><br>

</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Jun 23, 2020 at 8:54 AM Ryan Sleevi via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org">servercert-wg@cabforum.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">The CA/Browser Forum doesn’t replace the need for Root Programs and their policies; it exists to help ensure that existing policies are auditable, in a way that can be used to provide independent assurance of compliance with Root Programs’ policies. It also provides a venue for Root Programs and CAs to discuss proposed policies and avoid unintentional conflicts among these policies. Because of this, the Baseline Requirements don’t really define “best practice” of any sort; they merely represent the collective minimum requirements that Root Programs find useful to have independent confirmation of.<br><br>When we think about how the Baseline Requirements developed, it wasn’t to replace Root Programs, but to provide additional independent assurance that the specific needs of Root Programs regarding TLS certificates were being followed, and for CAs it was to record and coordinate those Root Program expectations in order to facilitate ongoing compliance requirements.<br><br>I realize that the core of the suggestion by Entrust Datacard is that Root Programs should no longer define their own requirements. There’s much that can be said about that, but I also think it may misunderstand why browsers participate in the Forum. If anything, it seems that this would have the effect of discouraging further participation by browsers. This is because Root Programs still need to define what is appropriate, for their products, to protect their users, and that’s something only the Root Program is capable of doing. The CA/Browser Forum exists to support that, not to replace that.<br><br>The effect of excluding certain requirements, as suggested, would seem to prevent audits such as those by WebTrust and ETSI from providing the independent assurance that Root Programs’ requirements are being met. This seems to be a step backwards, especially for CAs, because that assurance needs to be provided somehow in order for CAs to be trusted, and is why CA audits were developed in the first place. Technical controls in client software are valuable, but they aren’t substitutes for independent assurance. Simply stating things in a CP/CPS, as GlobalSign has proposed, isn’t useful without specific independent controls to evaluate those statements, as ample experience and evidence has shown.<br><br>How should Root Programs achieve the independent assurance that their requirements are being met? I see several possible outcomes, should this ballot fail:<br><ol><li>Root Programs work to develop their own audit criteria, either alone or together, continuing with valuable input from CAs, but structured in a way to reflect the unmet industry needs of these Root Programs.</li><ul><li>Audit standards would be accepted if, and only if, they incorporated such Root Program Requirements as part of their audited criteria and controls.</li><li>This would have the most likely effect of requiring multiple audits, which may come at greater cost to CAs in order to demonstrate independent assurance about the compliance to various Root Programs’ requirements.</li></ul><li>Root Programs require Agreed Upon Procedures (AUP) reports, allowing CAs to demonstrate via independent assurance their compliance with various specific requirements.</li><ul><li>This would require even more audits, as the AUP needs to be defined by the contracting entity (e.g. the Root Program) in order to achieve the appropriate level of assurance. The CA defining the criteria for the AUP would not provide Root Programs the necessary assurance, per professional standards regarding such reports.</li><li>There are significant international limitations on the use of AUPs, especially with respect to ETSI. This would have the effect that ETSI audited CAs would need to achieve an audit under the appropriate international accounting standards for AUPs.</li><li>Beyond the increase in audits for CAs, this would require significantly greater investment by Root Programs in order to appropriately contract with the auditors for these AUPs. It seems not unreasonable that this cost be carried by  CAs, since ultimately, it is for the CA's benefit and because the CA must demonstrate compliance with the program requirements.</li></ul><li>Root Programs require the equivalent of Detailed Control Reporting, as has been discussed for several years in the CA/Browser Forum, and only accept reports in which the CA has demonstrated implementation of all controls that comply with all Root Program requirements.</li><ul><li>This has the benefit of potentially allowing for a single audit, although these detailed control reports are significantly more expansive in scope, and thus incur greater cost to CAs to procure.</li><li>This further has the downside of precluding ETSI ESI, as despite years of effort in working the WebTrust TF, ETSI and ACAB'c have not produced any work that demonstrates an equivalent level of detail, assurance, and consistency, both to international standards and to industry needs.</li><li>It has the downside that if a CA fails to include such a control in their report, it may result in the removal of trust in the CA or necessitate a new audit, potentially from a new auditor, at the expense of the CA.</li></ul><li>Root Programs invert the audit flow, such that each Root Program contracts with the auditor and establishes the requirements, as the norm in other industries making use of third-party audits.</li><ul><li>In this model, each Root Program selects and contracts the auditor, in order to ensure that the criteria are clear and consistent and aligned with that Root Programs' needs.</li><li>This is already incorporated into some Root Programs' requirements and contracts, and so it provides the most natural starting point.</li><li>The client is the Root Program, but the cost of the audit is covered, directly or indirectly, by the entity being audited and seeking recognition by the Root Program, namely, the CA.</li></ul></ol>All of these seem to incur significant costs to CAs, and reflect the reality that the primary activity of the CA/Browser Forum exists to help offset some of those costs, by developing a useful set of Baseline Requirements that allow for easy portability of audits among Root Programs. If the CA/Browser Forum is unable to provide that level of independent assurance, it seems essential that Root Programs look elsewhere. This seems a very costly proposition for CAs, as opposed to the much easier solution of incorporating directly as this ballot proposes.<br><br>But this requires we still go back to looking at why the CA/Browser Forum exists and why it’s useful. The Baseline Requirements, and audits in general, don’t exist to replace Root Programs requirements. Root Programs use the Baseline Requirements, and accept audits based on them, only because they’re aligned with what the Root Program needs, not because they define that need.<br><br>CAs are valuable partners in this process of developing and expressing requirements. The experience and feedback from CAs helps develop clearer requirements, ideally with auditable controls. The feedback from CAs can provide a useful additional perspective, adding to the many feedback channels a browser vendor already has and uses. The voting structure of the Forum is particularly useful in helping ensure that a small group of CAs cannot propose requirements that disadvantage competitors, by helping ensure that CAs’ proposed solutions are reflective of CA consensus. However, Root Programs are ultimately responsible for deciding and declaring their requirements, and will continue to do what’s necessary to protect their users and their products.<br><br>If the Baseline Requirements fall out of alignment with Root Programs’ needs, it’s easy to imagine them replaced with an audit scheme or approach that meets Root Programs’ needs, such as those outlined above. The CA/Browser Forum could continue to develop voluntary criteria, and CAs could work to obtain audits based on this criteria, but that wouldn’t be sufficient to be trusted within a Root Program, because the audits wouldn’t reflect what that Root Program expects. As Root Programs will continue to take steps to protect the security and privacy of their users, an outcome of SC31 failing, in its full and current form, would be a strong signal to Root Programs that the CA/Browser Forum is unwilling or unable to develop requirements that reflect Root Program’s needs.<br><br>It also seems that the suggested proposal, of Root Programs’ no longer developing their own requirements and only introducing requirements that a majority of CAs have agreed to, would have the effect of further discouraging Root Programs from participation in the CA/Browser Forum. If a Root Program recognizes an important security need for their users, of course they’ll continue to take steps to protect their users security and privacy. The entire reason for Root Program requirements in the first place is to help protect that Root Program’s users, by making sure the Root Program is confident that there are sufficient safeguards in place at CAs. There doesn’t seem to be any benefit to Root Programs, and only significant and unnecessary risk to their users, by allowing necessary improvements to be delayed or blocked by CAs.<br><br>As Ballot SC31 shows, the vast majority of these changes have had no prior discussion in the CA/Browser Forum, and were directly added to Root Programs. Tellingly, it seems that the only requirement facing push back is one which was previously discussed in the Forum. It’s quite reasonable for a Root Program to conclude that the best solution is to introduce requirements outside of the CA/Browser Forum, as they have for every other change in SC31, and only fold them back into the Forum after the fact. However, at that point, it seems that it would be easier for Root Programs to then also fully develop and own the audit criteria, such as the options outlined above, which provides greater assurance and lowers the total cost of operating a Root Program. That seems a step back, but it may be the only other alternative.</div>
_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" rel="noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br>
</blockquote></div>