Yes, we can punt the problem down a few years, by allowing CAs to self-report in unauditable ways, and shift the burden of evaluation on to the community to try and detect CAs misbehaving.
Or we can take sensible steps forward that nip the problem at its root, don’t require misunderstanding or misusing unrelated technologies, and instead achieve the goals that CAs have been claiming are valuable to achieve years sooner. Obviously, simpler is better - and a whitelist of QGIS quickly establishes an interoperable and consistent baseline for organizational information, and can be readily deployed today, without any unnecessary infrastructure, and with immediate utility to existing relying parties. On Fri, Sep 28, 2018 at 7:43 PM Tim Hollebeek <[email protected]> wrote: > Perhaps a simple first step is to mandate disclosure of which information > source was used for validation. Then if someone uses Google Maps or > similar, People Who Pay Attention To Such Things can start a public > discussion about whether the source is a QIIS, and whether the certificate > is mis-issued. > > This would be yet another use case for my certificate metadata transparency > idea. CAs have lots of information about the validation, issuance, > management, and revocation of certificates that really does not need to be > private. As I've noted a few times this year, the issue keeps coming up. > > If there were more hours in my day, there'd be an RFC for it already. If > anyone wants to help with it, I'd be more than happy to work with them. > > -Tim > > > -----Original Message----- > > From: dev-security-policy <[email protected] > > > On > > Behalf Of Ryan Sleevi via dev-security-policy > > Sent: Friday, September 28, 2018 10:04 AM > > To: Dimitris Zacharopoulos <[email protected]> > > Cc: mozilla-dev-security-policy > <[email protected]>; > > Ian Carroll <[email protected]> > > Subject: Re: Concerns with Dun & Bradstreet as a QIIS > > > > On Fri, Sep 28, 2018 at 1:22 AM Dimitris Zacharopoulos via > dev-security-policy > > <[email protected]> wrote: > > > > > > > > Forgive my ignorance, but could you please explain what was your > > > ultimate goal, as "an attacker", what were you hoping to gain and how > > > could you use this against Relying Parties? > > > > > > I read your email several times but I could not easily find a case > > > where your fake address creates any serious concern for Relying > > > Parties. Even if you used the same street address as CloudFlare, the > > > CA would check against the database and would find two company records > > > that share the same address. That would obviously block the process > > > and additional checks would take place. Now, as a way to delay > > > certificate issuance for CloudFlare, I find it interesting but it > > > certainly doesn't seem to affect Relying Parties. > > > > > > > I'm not Ian, but I would have thought his email would have been obvious > and > > clear. The confusion here is that two jurisdictions can allow different > entities > > the same name. The EVGs seek to resolve this by making use of a variety > of > > ancilliary fields - such as serialNumber and the incorporation > information > - to > > presumably attempt to establish to the relying party the identity they're > > speaking to. > > > > In the "Stripe, Inc" case, the user was able to distinguish 'real' from > 'fake' by > > virtue of the incorporation information - Kentucky vs California. > > However, in this case, the attack went further, in as much as through the > CA > > using an unreliable datasource to verify the jurisdictional information. > > If the CA used an unreliable datasource, then the end user would see > > something that, for intents and purposes, appears the same. > > > > I'm not sure your point about the same address - Ian made it clear it was > a > > different but *similar* address - and I'm not sure why you suggest it > would > > block for the legitimate subscriber. Does that explain it simply enough? > > > > > > > And to take this one step further, I believe there are several GISs > > > that also accept whatever address you tell them because: > > > > > > 1. They have no reason to believe that you will lie to them (they know > > > who you are and in some Jurisdictions you might be prosecuted for > > > lying to the government) > > > 2. No foreseeable harm to others could be done if you misrepresent > your > > > own address. > > > > > > > Then they are not Reliable nor QIISes. Full stop. > > > > > > > In my understanding, this is the process each CA must perform to > > > evaluate every Data Source before granting them the "Reliable" or > > > "Qualified" status. Self-reported information without any supporting > > > evidence is clearly not acceptable. I have not evaluated this database > > > that you mention but if they accept self-reporting for "Street Address" > > > and don't perform any additional verification (like asking you for a > > > utility bill or cross-referencing it with a government database), then > > > the "Street Address" information is unreliable and the CA's evaluation > > > process should catch that. > > > > > > That doesn't mean that the rest of the information is also unreliable. > > > For example, an Information Source might describe in their > > > documentation practices how they verify each piece of information, for > > example: > > > > > > > I disagree with this assessment, and I think it's precisely why greater > > restriction is needed on the flexibility of CAs to make such > interpretations. I > > understand the point you're trying to make - why throw the baby out with > the > > bathwater - but to its use within the EVGs and the BRs, such structural > issues > > throw into fundamental question the status as a RDS or QIIS. > > > > As you highlight, this is an assessment that each CA makes, according to > its > > own processes and skills, and based on their own understanding. > > Auditors, which while required to have professional understanding of the > > relevant standards but are by no means omniscient nor experts, then also > > review these processes. Thus, we can easily end up in a situation where > CA > A > > determines that Foo is an RDS and QIIS for (Address, Serial Number), > while > CA > > B determines that Foo is an RDS and QIIS only for (Serial Number). > > > > For an adversarial model, however, the strength of CA B's understanding > and > > recognition that Foo is not suitable as a QIIS for Address is irrelevant, > as an > > adversary needs only obtain a certificate from CA A instead. While I'm > sure CA > > B would love to market and crow about their excellence in the market for > > recognizing that Foo was not a QIIS for Address, to the end user, > browser, > and > > relying party, the fact that CA B deserves a cookie and a pat on the back > is > > irrelevant. > > > > This is because the goal of a given root program is to ensure a > consistently > > operated PKI with a consistent degree of assurance. That CA A accepts Foo > as a > > QIIS and CA B does not, because they both participate in the same PKI > > (namely, the browser's root program), the levels of assurance are not > equal to > > the expectations of the policy. One model of approaching this is to try > to > > outsource that lack of assurance to the relying party - for example, > telling > > them that "CA A shouldn't be relied upon" or "CA B is more trustworthy" - > but > > for the Web, that's a fundamentally failed model full of user-hostility. > The > > other approach is to establish more consistent criteria to assess CA A > and > CA B > > against, to reduce the divergence in assurance - which is where a > whitelist > > comes from. > > _______________________________________________ > > dev-security-policy mailing list > > [email protected] > > https://clicktime.symantec.com/a/1/YhGZos1avY3eKvMWKYlmLu1ii28BaqX5h > > enyGbAJ5EY=?d=qYFp5yYkROrafPELVxZ46o5rfBVUzBR1PCFPo4qD5MguYYTrSY > > My6BxhqJFYwXl1DE7irkYWqyBqAhPuIWyDnqqdby9NLQaPW2qd7vmFFVSr1ho > > LCdp-l4LtbLHD8JeP3Ac9km0ARlqmleBd__LH7NYWCsRGWT2YNYWUVM- > > CUIBVDC8Kb0fuERJWO9tJv9qeAaccg_uBko09aMAW0uAgPIxRsrLuDrHQttxima > > UeizHsrnLnK5hghSjCdHJlQlZV9PYYF6zv_eiIE5au- > > qiI3aLCRhoB5J86pb9_WZQUHKZo8vKEjQ5swiyLRct5TOAdbvlmIH7KztTEgJrndI > > mm6lNGbPXr2LTyldgjBd7gnVU6fU8Aau46fKFSNWnsueNVprp2Qka8Hc7KNi7oJ > > 3R5GIsF0yFMlL5Oje00H9b7p2- > > NasIMD_A5A8t_0pQGrB85yg%3D%3D&u=https%3A%2F%2Flists.mozilla.org%2 > > Flistinfo%2Fdev-security-policy > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
