<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 22, 2019 at 2:17 PM Robin Alden <<a href="mailto:robin.alden@sectigo.com">robin.alden@sectigo.com</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 lang="EN-GB"><div class="gmail-m_-7243489713877224885WordSection1"><p class="MsoNormal">Ryan,<u></u><u></u></p><p class="MsoNormal" style="text-indent:36pt">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 <u></u><u></u></p><p class="MsoNormal" style="text-indent:36pt"><u></u> <u></u></p><p class="MsoNormal">Stephan Wolf said:<u></u><u></u></p><p class="MsoNormal">> > My understanding of the formation of the Forum was always about adopting<u></u><u></u></p><p class="MsoNormal">> > “best practices” by strong consensus of the CA and browser community,<u></u><u></u></p><p class="MsoNormal">> > acting cooperatively and by consensus.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Ryan Sleevi said:<u></u><u></u></p><p class="MsoNormal">> "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.<u></u><u></u></p><p class="MsoNormal">> <snip><u></u><u></u></p><p class="MsoNormal">> That is the sole and only purpose of the Forum. Any other suggestion is ahistorical and not reflected in the past or present activities."<br><br><span><u></u><u></u></span></p><p class="MsoNormal"><span>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.  <u></u><u></u></span></p><p class="MsoNormal"><span><u></u> <u></u></span></p><p class="MsoNormal"><span>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”.<u></u><u></u></span></p><p class="MsoNormal"><span><u></u> <u></u></span></p><p class="MsoNormal"><span>I accept that it could be the view of a representative from a browser that the only point of the forum is as “a </span>venue to ensure Browsers do not place conflicting requirements on CAs”.<u></u><u></u></p><p class="MsoNormal">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.</p></div></div></blockquote><div><br></div><div>I think we're in quite a bit more agreement than disagreement.</div><div><br></div><div>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).</div><div><br></div><div>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).</div><div><br></div><div>So now let's circle back:</div><div>1) Why is the CA/B Forum relevant?</div><div>  - The CA/B Forum is relevant because it develops documents like the Baseline Requirements</div><div>2) Why are the Baseline Requirements relevant?</div><div>  - The Baseline Requirements are relevant because they are useful to inform audit criteria like WebTrust for CAs or ETSI EN 319 411-2</div><div>3) Why are audit criteria like those relevant?</div><div>  - Those audit criteria are relevant because they're used by Browser Root Programs</div><div>4) Why do Browser/Root Programs use those Audit Criteria?</div><div>  - 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</div><div>5) Why do Browser/Root Programs define requirements?</div><div>  - 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).</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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"</div><div><br></div><div>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'.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div></div></div>