[Servercert-wg] Ballot SC31 - Browser Alignment
Ben Wilson
bwilson at mozilla.com
Tue Jun 23 16:04:43 MST 2020
Dear Colleagues,
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.
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.
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].
As Mozilla’s Root Store Policy says [5]:
1.
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.
2.
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.
3.
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.
4.
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.
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.
Regards,
Ben Wilson
Mozilla CA Program Manager
References:
[1] https://github.com/mozilla/pkipolicy/issues/204
[2] https://wiki.mozilla.org/CA/Communications#May_2020_CA_Communication
[3]
https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J000042AUSv&QuestionId=Q00105,Q00106,Q00107
[4]
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy#12-policy-ownership
[5]
https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy
[6]
https://github.com/mozilla/pkipolicy/issues?q=is%3Aissue+is%3Aopen+label%3A2.7.1
On Tue, Jun 23, 2020 at 8:54 AM Ryan Sleevi via Servercert-wg <
servercert-wg at cabforum.org> wrote:
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> How should Root Programs achieve the independent assurance that their
> requirements are being met? I see several possible outcomes, should this
> ballot fail:
>
> 1. 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.
> - Audit standards would be accepted if, and only if, they
> incorporated such Root Program Requirements as part of their audited
> criteria and controls.
> - 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.
> 2. Root Programs require Agreed Upon Procedures (AUP) reports,
> allowing CAs to demonstrate via independent assurance their compliance with
> various specific requirements.
> - 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.
> - 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.
> - 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.
> 3. 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.
> - 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.
> - 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.
> - 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.
> 4. 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.
> - 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.
> - This is already incorporated into some Root Programs'
> requirements and contracts, and so it provides the most natural starting
> point.
> - 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
> 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.
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200623/3dc552ca/attachment-0001.html>
More information about the Servercert-wg
mailing list