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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
