[Servercert-wg] Ballot SC31 - Browser Alignment

[Ryan Sleevi]

On Thu, Jul 2, 2020 at 12:37 AM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

> 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.
>
>    - The burden of proof for proposed ballots has historically rested
>    upon the proposer, regardless of the voting category.
>    - 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.
>    - 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."
>
> This fundamentally misunderstands CAs in such a way that it deeply
misrepresents things.

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.

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.

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.

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.
https://www.digicert.com/news/digicert-selected-to-operate-managed-pki-for-usb-type-ctm-authentication/

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.

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.

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.

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.

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.


> 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.
>

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.

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.

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.


> 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.
>

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