<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Thank you for the detailed response. I have some answers inline.<br>
<br>
<br>
<div class="moz-cite-prefix">On 2020-07-02 10:20 μ.μ., Ryan Sleevi
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACvaWvYXNUQmH6+BFov5pFtKJtALXYKKupoyJ=opanUwog1E_w@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<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" moz-do-not-send="true">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/"
moz-do-not-send="true">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>
<br>
As we have discussed several times in the past, mixed hierarchies
are already in existence. Apple and Mozilla uses Roots for both
id-kp-emailProtection and id-kp-serverAuth. Microsoft uses Roots for
id-kp-codeSigning too. If there is a goal to separate these
hierarchies per EKU, then let's all agree on such a goal and proceed
accordingly. <br>
<br>
Until now, I haven't seen any definitive positions by Certificate
Consumers asking CAs to separate their hierarchies. Once we had
that, it wouldn't be hard to create a transition plan and separate
the hierarchies. <br>
<br>
<br>
<blockquote type="cite"
cite="mid:CACvaWvYXNUQmH6+BFov5pFtKJtALXYKKupoyJ=opanUwog1E_w@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
<br>
For the 270-290 Intermediates, some of them chain to a Root with
such a common hierarchy (for TLS, emailProtection, codeSigning,
timeStamping, docSigning, etc) and the end-entity certificates
cannot last for 7 days (consider for example EV Code Signing
Certificates where the keys must be generated in FIPS devices). Your
request to revoke such non-TLS Issuing CAs is because they "touch"
the common Root (which is capable for TLS), thus becoming in Scope
of the Baseline Requirements. Issuing 7-day Certificates for these
non-TLS Certificates wouldn't solve this problem.<br>
<br>
<blockquote type="cite"
cite="mid:CACvaWvYXNUQmH6+BFov5pFtKJtALXYKKupoyJ=opanUwog1E_w@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote">
<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>
</blockquote>
<br>
As you have repeatedly said, Audits are just one factor Browsers
consider. Obviously Browsers see some merit in independent audits,
especially for operations and processes that have no external
visibility. My point was that especially for the 398-day Root Store
policy requirement, the technical means at your disposal are very
solid. I didn't mean anything further than that. I explained why I
believe the Forum brings added value. It is to build wider Industry
consensus and bring collective experience by industry experts.<br>
<br>
<br>
Dimitris.<br>
</body>
</html>