<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 2, 2020 at 12:37 AM Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr">dzacharo@harica.gr</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>
<div>On the topics mentioned on a personal capacity, it was really hard
to reply to your points because your responses shifted the
discussion to other areas which were never intended in my initial
email. Here is an attempt to respond to some of your statements.<br></div>
<ul>
<li>The burden of proof for proposed ballots has historically
rested upon the proposer, regardless of the voting category.</li>
<li>In this SCWG (under the CA/Browser Forum Bylaws), CAs don't
"prefer to dictate the terms on browsers" and neither should the
Certificate Consumers (in the SCWG case, "the Browsers").
Browsers already "dictate" anything they choose via their Root
programs in addition to the Baseline Requirements.</li>
<li>Your analogy was not very accurate. A more appropriate analogy
would be "The customer wants 2lt bottles of milk but the State
forces giving them 1lt bottles of milk. The customer is
frustrated, asking for the security reasons why 2-lt bottles are
problematic, and the State is giving reasons that the customer
doesn't understand or feels they are not adequately justified or
founded. The customer will try to get 2-lt bottles but after
some time, stores that want to abide by the State laws will only
be selling 1lt bottles of milk (or risk being put
out-of-business). If this customer went to another State,
perhaps there would not be a ban for 2-lt bottles."</li></ul></div></blockquote><div>This fundamentally misunderstands CAs in such a way that it deeply misrepresents things.</div><div><br></div><div>Browsers are not "the State". CAs are not at risk of going out of business. No one is being prohibited from offering long-lived certificates.</div><div><br></div><div>CAs provide a service for browsers. Your analogy, again, tries to shift it as if the site operators are CA's customers, but that fundamentally misunderstands the role of CAs and Browsers. From the very first invocation of audits and the introduction of hybrid PKIs (with respect to ITU-T's X.590v3), the model is that those that federate with a PKI - e.g. the Browser - are the consumers/customers of that PKI.</div><div><br></div><div>An Audit exists, and is defined by, the consumer (the Browser), to demonstrate that the needs of the consumer (the Browser) are met, so that they can do business with the CA and recognize the CA as appropriate to meet their business needs. It is no different than the selection of a software or hardware vendor or supplier: CAs provide a service for Browsers by performing website validation for that browser, to promote interoperable solutions. Whether I use CDW or Dell or HP or build my own servers, it is the same thing: different service providers that provide different services to help a customer (the Browser) achieve their goals.</div><div><br></div><div>This is demonstrably no different than the role that CAs play in platforms involving code signing: they provide a service for that consumer. Countless Members in this Forum operate other PKIs for entities, and there's seemingly no confusion about such relationships between operating managed CAs. When DigiCert operates the USB-C IF PKI, they are operating it on behalf of the USB-C IF, and in order to meet the needs of the USB-C IF. <a href="https://www.digicert.com/news/digicert-selected-to-operate-managed-pki-for-usb-type-ctm-authentication/">https://www.digicert.com/news/digicert-selected-to-operate-managed-pki-for-usb-type-ctm-authentication/</a></div><div><br></div><div>Fundamentally, a CA that is "trusted" is simply one that is operating a Managed CA on behalf of the Browser. This seems like a radical statement, but is the very core and foundational aspect that is so key to understanding our differences of perspective. The consumer is the Browser, and a particular PKI is being operated for their Benefit.</div><div><br></div><div>HARICA, as with any other CA, is free to issue certificates for however long they want, and from any other PKI they operate. None of the discussion here impinges upon that. However, for the PKI operated for browsers such as Google, Apple, or Mozilla, any CA needs to abide by those rules. The CA is providing a service - to the browser - and the browser will go elsewhere if the service is no longer valuable, useful, or meeting their needs.</div><div><br></div><div>CAs are like factories that produce physical goods. They contract with a customer (the Browser), to produce a good according to the customer's specifications. The customer wants to supervise production, because it's their reputation and their customers that are harmed if, say, the factory uses lead-based paint or produces shoddy products. The customer wants to make sure that all of the raw materials they supply to that factory are used to producing their goods, and aren't siphoned off to produce knock-offs or to produce other customers' goods.</div><div><br></div><div>These are concepts that few people struggle with, because they are the gears of our modern interconnected world. It's perhaps unsurprisingly why the audits developed by ETSI use an ISO methodology that is frequently used for the certification of goods production. CAs are an assembly line for certs, but the product they're making is on the behest of the customer, and the requirements are at the behest of the customer: the browsers. Everything discussed in this whole thread has fundamentally been trying to make that clearer.</div><div><br></div><div>The suggestion to "go create something else" is no different than the existence of the USB-IF, for example. It helps coordinate the different customers (browsers, or in this case, USB device manufacturers) to provide a singular voice for the CA (DigiCert, in the above example), to deal with when operating that Managed CA.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>HARICA supports the ballot including the 398-day limit, but I fully
understand and respect the position of other CAs which "in
principle" don't support this to be included in the BRs. In
practice, Browsers shouldn't need this to be included in the BRs or
rely on audits. </div></blockquote><div><br></div><div>This sort of "absolute" language is entirely dismissive, and highlights the failing comity of the Forum. I can understand if you don't understand the reasons, but to state it as an absolute is to dismiss the countless good-faith efforts made over the past 5 years to explain these concerns.</div><div><br></div><div>I also fail to see how it *isn't* still understood, especially as we look at approximately 270-290 misissued intermediate certificates needing revocation within the next 7 days. Any pain caused by that is a direct consequence of those intermediates being used for longer than needed, which is directly proportional to the sum of certificates they have issued and the maximum lifetimes of those certificates.</div><div><br></div><div>Put differently: If certificates were only valid for 7 days, then the full and prompt replacement of every one of those intermediates posing security risk would be completed, on time, and without any issues. Every day longer that a certificate is valid for only serves to increase the impact of that revocation, thus incentivizing the CA to fail to meet their contractual obligations, and thus worsening or exacerbating the security impact to browsers and end users. This should be trivial to scratch out on paper and see how it works out.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>With Certificate Transparency, they can technically
detect whether a certificate has been issued with validity more than
398 days and discover a possible Root Program policy violation. So,
from my perspective I don't understand why such extreme language is
used, for a topic that Browsers already have full technical control
and don't need to rely on audits or the BRs.<br></div></blockquote><div><br></div><div>Then why do we need the Forum at all? If Browsers don't need to rely on audits or the BRs, and the Forum exists to develop the BRs to support audits, then there is no need for the Forum.</div><div> </div></div></div>