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://lists.mozilla.org/listinfo/dev-security-policy
