[Servercert-wg] Ballot SC31 - Browser Alignment

[Ryan Sleevi]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200623/f7929495/attachment.html>