Kirk, may I remind you that Ryan Sleevi is posting in personal capacity here, as is the default on m.d.s.p unless otherwise specified. So please do not drag his employer into this discussion.
Ryan SleeviPeer of the CA Certificates Module <https://wiki.mozilla.org/Modules/All#CA_Certificates>; Works for Google <https://www.google.com/>; PKI policy for Chrome/ChromeOS; Posting in a personal capacity, with posts not necessarily representing the views of Google or the Mozilla CA Certificate Module, except where otherwise noted. From: https://wiki.mozilla.org/CA/Policy_Participants - Cynthia On Sun, Sep 22, 2019 at 6:56 AM Kirk Hall via dev-security-policy < [email protected]> wrote: > On Saturday, September 21, 2019 at 6:19:29 PM UTC-7, Ryan Sleevi wrote: > > On Sat, Sep 21, 2019 at 7:52 PM Kirk Hall via dev-security-policy < > > [email protected]> wrote: > > > > > To remedy this, Entrust Datacard surveyed all of its TLS/SSL web server > > > certificate customers over three days (19-21 September 2019) concerning > > > website identity in browsers, browser UIs in general, and EV browser > UIs in > > > particular. We have received 504 responses from customers to date, and > > > more responses are still coming in. Respondent company size ranged all > the > > > way from 1-99 employees to over 20,000 employees. > > > > > > Thanks for sharing this interesting marketing data by Entrust DataCard. > > It's always good to see the marketing teams able to reach out to their > > customers, as it gives hope that there's improvements being made to > ensure > > timely revocation. > > > > Since numbers like "92%" sound quite large, unless and until they're put > > into context, I wanted to make sure there was a clear picture about what > > those 504 responses represent. > > > > 1) Based on Entrust Datacard's CP/CPS, it only issues OV/EV certificates. > > Is this correct? This is largely to account for self-selection issues, > > since one might expect 100% of respondents that have already chosen a > > particular service to, well, respond in similar numbers. > > > > 2) Related, looking at the numbers published by Firefox Telemetry, over a > > two month period of connections made by Firefox users, only a small > > fraction, approximately 0.3%, encounter certificates from Entrust > DataCard. > > This is roughly 120 million connections out of 39.49 billion. Does that > > match Entrust DataCard's analysis about the size of its customer base? > > > > You can check the math at telemetry.mozilla.org, > > using CERT_VALIDATION_SUCCESS_BY_CA as the metric. Based on > RootHashes.inc, > > it appears Entrust DataCard operated CAs are the buckets 10, 18, 109, > 110, > > 111, 112, 163, and 164, which matches the 8 CAs Entrust has disclosed in > > CCADB that are trusted by Mozilla. Three of these CAs have seemingly not > > been used to verify any connections, while of the remaining 5, it seems > > that only Entrust Root Certification Authority - G2 sees any real use. > > > > 3) Are the numbers Entrust DataCard provided in > > > https://cabforum.org/wp-content/uploads/23.-Update-on-London-Protocol.pdf > > still accurate? That is, do EV certificates account for only 0.48% of the > > certificate population? > > > > If those numbers are correct, this seems like it's a survey that > represents > > a small fraction of Entrust DataCard's customers (unless Entrust DataCard > > only a few thousand customers), which represents a small fraction of > > connections in Mozilla Firefox (approximately 0.3% over a 2 month > period), > > regarding certificates that account for only 0.48% of the certificate > > population. > > > > Is that the correct perspective? > > The data I posted is correct, so I'm not really sure what point(s) you are > making. > > Does Google Chrome have any data from its own surveys of website owners' > opinions it's willing to share? It's one thing to be a critic of the work > of others, it's another thing to actually create useful and meaningful data > yourself and share with the Mozilla community. > > What data from Chrome can you share with us? > _______________________________________________ > dev-security-policy mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
