On Tuesday, October 2, 2018 at 7:02:32 AM UTC-7, Dimitris Zacharopoulos wrote: > On 1/10/2018 8:15 μμ, Ryan Sleevi via dev-security-policy wrote: > > On Mon, Oct 1, 2018 at 9:21 AM Dimitris Zacharopoulos <[email protected]> > > wrote: > > > [...] > > > > > >> I am certainly not suggesting that CAs should put inaccurate and > >> misleading information in certificates :-) I merely said that if the > >> Subscriber introduces misleading or inaccurate information in certificates > >> via a reliable information source, then there will probably be a trail > >> leading back to the Subscriber. This fact, combined with the lack of clear > >> damage that this can cause to Relying Parties, makes me wonder why doesn't > >> the Subscriber, that wants to mislead Relying Parties, just use a DV > >> Certificate where this probably doesn't leave so much evidence tracing back > >> to the Subscriber? > >> > > "The lack of clear damage" - I'm not sure how better to communicate, since > > we're discussing fundamental damage to the value that OV and EV are said to > > provide. The only way we can say "lack of clear damage" is to say that OV > > and EV are worthless - otherwise, it's incredibly damaging. > > I'm actually still waiting for Ian to elaborate if the "attack" was just > the insertion of an intentionally wrong address in an EV Certificate or > if he was attempting something else. Although his attempt failed (no > Certificate was issued with that wrong Street Address), I consider the > discussion that followed very useful (at least to me).
Yes, that was the attack. As Ryan has said, if the organizational data in the certificate is not reliable, then EV brings no value-add. Of note, given the location of this forum, is that Firefox shows locality information in its expanded EV indicator, so this false data has a clear impact to the (likely very) small subset of users who click on it. I can appreciate that HARICA validates the data sources it uses for certificate issuance, but this is clearly not happening with US-based CAs, as the usage of D&B should be plainly demonstrating. It also seems like a stretch to me that CAs should be relying on third-parties to self-attest, in contracts or otherwise, that this validation occurs. As one would expect, D&B has a strong incentive to assert that they perform whatever validation the CA expects, regardless of their actual procedure. It makes no sense that QIISes are not audited along with the CA for their own record-keeping. The relationship between CAs and D&B is a bit weird, from what I've seen. A Comodo validation agent actually emailed me a screenshot of the UI they were using to search D&B, and it was a public site anyone could use to make an account. It's unclear to me if there is any sort of payment or actual contractual obligations between CAs and D&B. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
