[Servercert-wg] Ballot SC31 - Browser Alignment
sleevi at google.com
Tue Jun 23 07:54:01 MST 2020
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
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
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
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’
2. Root Programs require Agreed Upon Procedures (AUP) reports, allowing
CAs to demonstrate via independent assurance their compliance with various
- 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
contract with the auditors for these AUPs. It seems not unreasonable that
this cost be carried by CAs, since ultimately, it is for the
and because the CA must demonstrate compliance with the program
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
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
- 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
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Servercert-wg