On Mon, Oct 1, 2018 at 2:55 AM Dimitris Zacharopoulos <[email protected]> wrote:
> Perhaps I am confusing different past discussions. If I recall correctly, > in previous discussions we described the case where an attacker tries to > get a certificate for a company "Example Inc." with domain "example.com". > This domain has a domain Registrant Address as "123 Example Street". > > The attacker registers a company with the same name "Example Inc." in a > different jurisdiction, with address "123 Example Street" and a different > (attacker's) phone number. How is the attacker able to get a certificate > for example.com? That would be a real "attack" scenario. > Yes, you are confusing things, as I would have thought this would be a 'simple' discussion. Perhaps this confusion comes from only thinking the domain name matters in making an 'attack'. If that's the case, we can do away with EV and OV entirely, because they do not provide value to that domain validation. Alternatively, if we say that information is relevant, then the ability to spoof any of that information also constitutes an 'attack' - to have the information for one organization presented in a different (logical, legal) organization's associated information. > Unless this topic comes as a follow-up to the previous discussion of > displaying the "Stripe Inc." information to Relying Parties, with the > additional similarity in Street Address and not just the name of the > Organization. If I recall correctly, that second "Stripe Inc." was not a > "fake" entity but a "real" entity that was properly registered in some > Jurisdiction. This doesn't seem to be the same attack scenario as getting a > certificate for a Domain for which you are not the owner nor control, but a > way to confuse Relying Parties. Certainly, in case of fraud, this leaves a > lot more evidence for the authorities to trail back to a source, than for a > case without Organization information. > This also seems to be fixing on the domain name, but I have no idea why you've chosen that as the fixation, as the discussion to date doesn't involve that. I don't think it's your intent, but it sounds like you're saying "It's better for CAs to put inaccurate and misleading information in certificates, because at least then it's there" - which surely makes no sense. > But they do have some Reliable and Qualified Information according to our > standards (for example registry number, legal representative, company > name). If a CA uses only this information from that source, why shouldn't > it be considered reliable? We all need to consider the fact that CAs use > tools to do their validation job effectively and efficiently. These tools > are evaluated continuously. Complete dismissal of tools must be justified > in a very concrete way. > No, they are not Reliable Data Sources. Using unreliable data sources, under the motto that "even a stopped clock is right twice a day", requires clear and concrete justification. The burden is on the CA to demonstrate the data sources reliability. If there is any reason to suspect that a Reliable Data Source contains inaccurate data, you should not be using it - for any data. > I would accept your conclusion for an Information Source that claimed, in > their practices, that they verify some information against a secondary > government database and the CA gets evidence that they don't actually do > that. This means that the rest of the "claimed as verified" information is > now questionable. This is very much similar to the Browsers checking for > misbehavior on CAs where they claim certain practices in their CP/CPS and > don't actually implement them. That would be a case where the CA might > decide to completely distrust that Information Source. > > I hope you can see the difference. > I hope you can understand that this is not an apt or accurate comparison. An organization that lacks a process, which is the case for unreliable data, is no different than an organization that declares a process but does not follow it. > I remember this argument being supported in the past and although I used > to agree to it, with the recent developments and CA disqualifications, I > support the opposite. That is, Subscribers start to choose their CA more > carefully and pay attention to the trust, reputation and practices, because > of the risk of getting their Certificates challenged, revoked or the CA > distrusted. > So you believe it's in best interests of Subscribers to have CAs distrusted, certificates challenged and revoked, and for relying parties to constantly call into question the certificates they encounter? And that this is somehow better than consistently applied and executed validation processes? I wish I could share your "Mad Max" level of optimism, but it also fails to understand that we're not talking about Subscriber selection, we're talking about adversarial models. The weakest link matters, not "market reputation", as much as some CAs would like to believe. > CAs are required to comply with very complicated standards and these > standards describe best practices on how to evaluate and re-evaluate > information sources. > > If CA A trusted the "street address" from a DS, used this information to > be included in Certificates and later during re-evaluation discovered that > this particular piece of information is unreliable, I would expect this to > be treated as an incident according to the current standards. The CA would > have to create a plan to mitigate this problem. Again, this depends on the > CA's decisions how to mitigate the problem. Others would revoke all the > affected certificates immediately, others would re-evaluate the "street > address" information using a different reliable source and revoke the > Certificates they were unable to re-verify, others would do nothing. It is > impossible to cover all possible cases and require equal treatment for > incidents. > Funny enough, that subjectivity you just described is not permitted of CAs, and for good reason. Every one of those certificates needs to be revoked, per 4.9.1.1 of the BRs. The CA has also material misstated its warranty for these certificates, per 9.6.1. > I fully support a white-list of RDS/QIS with global acceptance and > collective scrutiny but even these lists need to be re-evaluated > periodically as required by our standards. Perhaps a "global black-list" > might be setup for certain cases of misbehavior like the one described > above. However, this white-list should not be the only one allowed to be > used and national jurisdiction databases (company registries) should also > be allowed provided they are adequately evaluated by the CA according to > our standards. > As anyone with any security background can tell you, whitelists address the objectives where blacklists address the appearances. If you believe that there are national jurisdictional databases, they can be added to the whitelist. Indeed, the entire point would be to ensure that, for the appropriate jurisdictional boundary, there's a clear indication as to appropriate data sources. Then, there is no need for CA discretion - or indiscretion. > I also support the idea of describing which information is evaluated as > "reliable" from a particular source and not completely dismiss a source if > they describe in their practices that they accept "some other" > irrelevant-to-the-ca information as self-reported. > So you would also see the whitelist broken down by jurisdiction and by data source. Unless and until there is a whitelist, there is no safe way to permit that usage you're describing. > It is a very challenging goal, especially because there are so many > different jurisdictions from which to collect reliable information. As a > more realistic goal, perhaps we could describe the ideal data source > evaluation and periodic re-evaluation process more explicitly in the > Guidelines, with clear and auditable criteria. > We're not short of describing expectations. We're short of CAs meeting expectations. And as I said, for an adversarial model, it does not matter what the best or 'most' do, it only matters what a single one permits. As such, a solution to "double down" on language that allows a CA to interpretive dance their way out of the objectives is not valuable, nor is any solution that relies on auditor review. Indeed, the main argument for 'auditable' criteria would be so that CAs could disguise their shady practices through a lack of transparent reporting, rather than the objective of this thread, which is to improve it through transparency. _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
