[Servercert-wg] Ballot SC31 - Browser Alignment

[Dimitris Zacharopoulos (HARICA)]

Thank you for the detailed response. I have some answers inline.


On 2020-07-02 10:20 μ.μ., Ryan Sleevi wrote:
>
>
> On Thu, Jul 2, 2020 at 12:37 AM Dimitris Zacharopoulos (HARICA) 
> <dzacharo at harica.gr <mailto: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.

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.

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.


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

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.

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

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.


Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200702/753f8ff7/attachment.html>