[cabfpub] The purpose of the CA/B Forum

[Ryan Sleevi]

On Tue, Oct 22, 2019 at 2:17 PM Robin Alden <robin.alden at sectigo.com> wrote:

> Ryan,
>
> Referring back to Dimitris’s reference [1], i.e. your response to Stephan
> Wolf, I think he (Stephan Wolf) probably overstated the forum’s purpose
> somewhat, but your response goes too far in the opposite direction to be
> considered accurate
>
>
>
> Stephan Wolf said:
>
> > > My understanding of the formation of the Forum was always about
> adopting
>
> > > “best practices” by strong consensus of the CA and browser community,
>
> > > acting cooperatively and by consensus.
>
>
>
> Ryan Sleevi said:
>
> > "The Forum provides a venue to ensure Browsers do not place conflicting
> requirements on CAs that voluntarily participate within the browsers root
> programs, by facilitating discussion and feedback.
>
> > <snip>
>
> > That is the sole and only purpose of the Forum. Any other suggestion is
> ahistorical and not reflected in the past or present activities."
>
> I think Stephan’s statement could have said ‘developing’ instead of
> ‘adopting’, ‘better practices’ instead of ‘best practices’, and he would
> have been pretty close to the mark.
>
>
>
> I had to look up ‘ahistoric’ in a dictionary, since it is not a word in my
> vocabulary, and one of the two definitions Merriam-Webster says it is
> “historically inaccurate or ignorant”.
>
>
>
> I accept that it could be the view of a representative from a browser that
> the only point of the forum is as “a venue to ensure Browsers do not
> place conflicting requirements on CAs”.
>
> However, if the other members of the forum are of the opinion that there
> is value in the activity of developing, not just receiving, even minimum
> requirements that may be used to raise the bar in the Web PKI, and
> especially if there are other parties within or without the forum that
> consider those minimum requirements as being worthy of adoption or
> formalization within their use of PKI, for the web or elsewhere, then that
> gives the forum purpose beyond the resolution of conflicting requirements
> and therefore your view of the forum is not accurate from the wider
> perspective.
>

I think we're in quite a bit more agreement than disagreement.

That is, the value of the Baseline Requirements is the same as any SDO work
product - it's only useful if it's adopted and used. The existence of
standards for standards sake is not useful, nor are standards themselves
imbued with some special power that make them worthwhile independently
(i.e. with no implementations).

This is why, for example, SDOs like the IETF say "Rough consensus and
running code" - equal in measure. Or, for that matter, the WHATWG take a
more direct approach - many of the documents (e.g. the URL standard, the
Fetch standard, CSS, or even HTML) are "Living Standards", in that they
reflect "What implementations do", not necessarily "What they ought to do"
(this was a somewhat significant divergence from the prescriptive model of
the W3C).

So now let's circle back:
1) Why is the CA/B Forum relevant?
  - The CA/B Forum is relevant because it develops documents like the
Baseline Requirements
2) Why are the Baseline Requirements relevant?
  - The Baseline Requirements are relevant because they are useful to
inform audit criteria like WebTrust for CAs or ETSI EN 319 411-2
3) Why are audit criteria like those relevant?
  - Those audit criteria are relevant because they're used by Browser Root
Programs
4) Why do Browser/Root Programs use those Audit Criteria?
  - They use them because it's a convenient short-hand for a common base
set of requirements that can be independently assessed and that are
nominally aligned with the critical aspects of their Browser/Root Program
Requirements
5) Why do Browser/Root Programs define requirements?
  - Because the use of certificates, particularly from third-party CAs, is
inherently a product security decision, and tied closely with the
reputation, needs, and desires of that Browser/Root Program and their
product(s).

The 'value' of the Baseline Requirements, as they stand today, flows down
from their use and adoption by Browser/Root Programs. And Browser/Root
Programs adopt them not because there is an intrinsic or inherent value to
them, but because they are useful if, and only if, they're aligned with the
Browser/Root Programs inherent requirements. If the Baseline Requirements
are not aligned with industry needs (read: Browser/Root Programs), then
Browser/Root Programs won't and shouldn't continue to use them, nor audit
criteria that are based on them. And if Browser/Root Programs don't use
these requirements, then there's limited value in them, and in the Forum
itself as the developer of them.

Browser/Root Programs don't use the Baseline Requirements inherently - they
use their Root Program Requirements, and accept the BRs only to the extent
they are aligned with those Root Program requirements.

For example, Browsers could fully decide that the WebTrust and the ETSI
approach to auditing don't actually meet the business need. There's
significant and compelling evidence that this is the case today, simply
based on how these audits are to be used versus what Browsers/Root Programs
want. Browsers could, for example, define their own audit criteria - either
individually or collectively - and/or select/define their own auditors.
There's no inherent requirement that they use the Baseline Requirements,
or, for that matter, consult with CAs - it's a product security question,
and they need to do what's right for their product security. In that case,
much of the 'value' of the Forum would be quickly eliminated, except as I
said - a discussion forum to avoid conflicting requirements and solicit
input.

Similarly, for that matter, we could see Browsers adopt models like DANE,
or adopt models that don't involve third-parties CAs at all (e.g. how much
of modern code signing works). Either of these models would similarly
obviate the need and value for the Baseline Requirements/for those browsers
to participate in the CA/Browser Forum.

I can understand the aspirational desire to use these in other use cases.
For example, wouldn't it "be nice" if, say, private PKIs used these
requirements? To some CAs, it may seem the answer is yes. I would firmly
argue that no, that it would only dilute the value received, because the
more generic you make a set of requirements, the less valuable it is. A
classic example is the genericity of the ETSI standards relating to audits,
and the fact that they act on a 2y iteration (full + surveillance) vs a 1y
iteration (as required by browsers). We know this has caused no end of
confusion and root program violation. This is what happens when you overly
genericize a set of requirements. Or look at SHA-1 discussions - the fact
that constituency X (e.g. Payment terminals) have differing requirements
than constituency Y (e.g. Browsers) is exactly why it's useful to have
separate requirements. Trying to unify those requirements means you will
only ever reach consensus on the "minimum set" - the "Baseline
Requirements" - because it fundamentally cannot be a universal "Good
practice"

The more ecumenical you make standards, the more you dilute the value.
Trying to please everyone is likely to please no one, and certainly not
meet or exceed what everyone 'wants'.

I can understand if some CAs disagree with that perspective. I would expect
so, and that's OK. However, while we could make the Forum "more", the
Forum's value today is inherently on making sure it serves that common base
need to providing a useful set of auditable criteria that are aligned with
what Browsers/Root Programs want/need/expect, and in providing a venue to
make sure that the things that go above and beyond (i.e. in Root Programs)
are not likely to cause conflicts. The moment the Forum and the BRs fail to
do that - whether it be because the Forum fails to adopt useful changes
that are expected by Browsers, whether Browsers change how they audit or
assess requirements, or whether Browsers change if and how they use CAs
altogether - the current Forum largely ceases to be relevant to the Web
PKI. It may reflect voluntary approaches - like the CA Security Council's
explorations - but those inherently don't make things more secure, more
trustworthy, nor do they necessarily enshrine good practice.

Could it achieve relevance by convincing others to adopt the Requirements?
Sure. But as with any "standard", if we want to argue the SDO-viewpoint,
the "standard" is only useful if it serves the needs of those who adopt.
The moment it stops doing that, the standard is forked or abandoned.

Could it adopt things that browsers disagree with? Sure. As with any
standard, however, browsers would simply say "Ignore that part" or "That
part isn't allowed". This would simply dilute the value for CAs, and
increase the costs/challenge for audits, and that does not seem aligned
with CAs' long-term interests.

There's still incredible value to be had in the Forum, if we can view
through the lens of providing useful, actionable, data-driven feedback.
That doesn't mean we have to always agree. It's especially important to
make sure it's clearly communicated what Browser/Root Programs "want" - in
order to make sure that's actually delivered, to ensure the BRs continue to
be relevant and useful inputs to the audit criteria that browsers/root
programs accept. And similarly, we should be mindful that permitting
something in the BRs, which is the majority of the Ballots that CAs have
sponsored in recent years, does not inherently make something good, nor
does it mean that Browsers/Root Program Requirements endorse or support
that view.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20191022/757d5c9b/attachment.html>