Re: Concerns with Dun & Bradstreet as a QIIS
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 > > 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 dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Concerns with Dun & Bradstreet as a QIIS
On 2/10/2018 5:21 μμ, Ryan Sleevi via dev-security-policy wrote: On Tue, Oct 2, 2018 at 10:02 AM Dimitris Zacharopoulos wrote: But this inaccurate data is not used in the validation process nor included in the certificates. Perhaps I didn't describe my thoughts accurately. Let me have another try using my previous example. Consider an Information Source that documents, in its practices, that they provide: 1. the Jurisdiction of Incorporation (they check official government records), 2. registry number (they check official government records), 3. the name of legal representative (they check official government records), 4. the official name of the legal entity (they check official government records), 5. street address (they check the address of a utility bill issued under the name of the legal entity), 6. telephone numbers (self-reported), 7. color of the building (self-reported). The CA evaluates this practice document and accepts information 1-5 as reliable, dismisses information 6 as non-reliable, and dismisses information 7 as irrelevant. Your argument suggests that the CA should dismiss this information source altogether, even though it clearly has acceptable and verified information for 1-5. Is that an accurate representation of your statement? Yes, I'm stating that the existence of and inclusion of 5-7 calls into question whether or not this is a reliable data source. Right, but in my example, the data source has already described -via their practices- that this is how they collect each piece of data. The CA, as a recipient of this data, can choose how much trust to lay upon each piece of information. Therefore, IMHO the CA should evaluate and use the reasonably verified information from that data source and dismiss the rest. That seems more logical to me than dismissing a data source entirely because they include "the color of the building", which is self-reported. Your parenthetical about how they check that is what the CA has the burden to demonstrate, particularly given that they have evidence that there is less-than-reliable data included. How does the competent CA ensure that the registry number is not self-reported - The information in the parenthesis would be documented in the trusted source practices and the CA would do an inquiry to check that these practices are actually implemented and followed. or that the QIIS allows it to be self-reported in the future? No one can predict the future, which is why there is a process for periodic re-evaluation. So let me understand: Your view is that QIIS's publish detailed policies about the information they obtain (they don't), and the CA must periodically re-evaluate that (which isn't in the BRs) to determine which information is reliable or not. EVG 11.11.5 says that "The CA SHALL use a documented process to check the accuracy of the database and ensure its data is acceptable, *including reviewing the database provider's terms of use*. The CA SHALL NOT use any data in a QIIS that the CA knows is (i) self-reported and (ii) not verified by the QIIS as accurate. Databases in which the CA or its owners or affiliated companies maintain a controlling interest, or in which any Registration Authorities or subcontractors to whom the CA has outsourced any portion of the vetting process (or their owners or affiliated companies) maintain any ownership or beneficial interest, do not qualify as a QIIS." I would assume that the "database provider's terms of use" describe the practices, so it is not fiction. Perhaps this doesn't apply for many information sources but it's not unheard of. As for the re-evaluation, we (HARICA) consider this part of ETSI EN 319 401 section 7.7 (Operational Security) with guidance provided by ISO/IEC 27002:2013 clause 15. I assume that WebTrust has something similar. Perhaps the connection is not so "direct" but when you depend on some external entity to provide any kind of information related to CA operations (in our case, the Subject information validation), then you must follow best practice and periodically re-evaluate. Presumably, that RDS/QIIS is also audited against such statements (they aren't) in order to establish their reliability. That's a great world to imagine, but that's not the world of RDS or QIIS, and so it's an entirely fictitious world to imagine. That world is either saying the RDS/QIIS is a Delegated Third Party - and all the audit issues attendant - or we're treating them like a DTP for all intents and purposes, and have to deal with all of the attendant DTP issues, such as the competency of the auditor, the scoping of the audits, etc. I see no gain from an overly convoluted system that, notably, does not exist today, as compared to an approach of whitelisting such that the CA no longer has to independently assess each source, and can instead work with the community to both report omissions of qualif
Re: Concerns with Dun & Bradstreet as a QIIS
On Tue, Oct 2, 2018 at 10:02 AM Dimitris Zacharopoulos wrote: > >> But this inaccurate data is not used in the validation process nor > >> included in the certificates. Perhaps I didn't describe my thoughts > >> accurately. Let me have another try using my previous example. Consider > an > >> Information Source that documents, in its practices, that they provide: > >> > >> > >> 1. the Jurisdiction of Incorporation (they check official government > >> records), > >> 2. registry number (they check official government records), > >> 3. the name of legal representative (they check official government > >> records), > >> 4. the official name of the legal entity (they check official > >> government records), > >> 5. street address (they check the address of a utility bill issued > >> under the name of the legal entity), > >> 6. telephone numbers (self-reported), > >> 7. color of the building (self-reported). > >> > >> The CA evaluates this practice document and accepts information 1-5 as > >> reliable, dismisses information 6 as non-reliable, and dismisses > >> information 7 as irrelevant. > >> > >> Your argument suggests that the CA should dismiss this information > source > >> altogether, even though it clearly has acceptable and verified > information > >> for 1-5. Is that an accurate representation of your statement? > >> > > Yes, I'm stating that the existence of and inclusion of 5-7 calls into > > question whether or not this is a reliable data source. > > Right, but in my example, the data source has already described -via > their practices- that this is how they collect each piece of data. The > CA, as a recipient of this data, can choose how much trust to lay upon > each piece of information. Therefore, IMHO the CA should evaluate and > use the reasonably verified information from that data source and > dismiss the rest. That seems more logical to me than dismissing a data > source entirely because they include "the color of the building", which > is self-reported. > > > Your parenthetical > > about how they check that is what the CA has the burden to demonstrate, > > particularly given that they have evidence that there is > less-than-reliable > > data included. How does the competent CA ensure that the registry number > is > > not self-reported - > > The information in the parenthesis would be documented in the trusted > source practices and the CA would do an inquiry to check that these > practices are actually implemented and followed. > > > or that the QIIS allows it to be self-reported in the > > future? > > No one can predict the future, which is why there is a process for > periodic re-evaluation. > So let me understand: Your view is that QIIS's publish detailed policies about the information they obtain (they don't), and the CA must periodically re-evaluate that (which isn't in the BRs) to determine which information is reliable or not. Presumably, that RDS/QIIS is also audited against such statements (they aren't) in order to establish their reliability. That's a great world to imagine, but that's not the world of RDS or QIIS, and so it's an entirely fictitious world to imagine. That world is either saying the RDS/QIIS is a Delegated Third Party - and all the audit issues attendant - or we're treating them like a DTP for all intents and purposes, and have to deal with all of the attendant DTP issues, such as the competency of the auditor, the scoping of the audits, etc. I see no gain from an overly convoluted system that, notably, does not exist today, as compared to an approach of whitelisting such that the CA no longer has to independently assess each source, and can instead work with the community to both report omissions of qualified sources AND report issues with existing qualified sources. That seems like a net win, without an unnecessary veneer of assurance that does not actually provide it (as shown by the issues with DTP audits for a number of CAs) > > This is where the 'stopped-clock' metaphor is incredibly appropriate. > Just > > because 1-5 happen to be right, and happen to be getting the right > process, > > is by no means a predictor of future guarantees or correctness or > accuracy. > > Of course, this is why you need re-evaluation. You can't guarantee > correctness for anything, otherwise we wouldn't have cases of > mis-issuance or mis-behavior. We add controls in processes to minimize > the risk of getting bad data. > > > More importantly, the inclusion of 5-7 in the reporting suggest that > there > > is *unreliable* data actively being seen as acceptable, and because of > > that, the CA needs to take a view against including. > > I am not sure if you have misunderstood my description, but let me > repeat that despite getting the full data set, the CA would use only the > information pre-evaluated as reliable, and that doesn't include > self-reported data which they know -beforehand- (because it is > documented in the data sour
Re: Concerns with Dun & Bradstreet as a QIIS
On 1/10/2018 8:15 μμ, Ryan Sleevi via dev-security-policy wrote: On Mon, Oct 1, 2018 at 9:21 AM Dimitris Zacharopoulos 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). For this particular case though, a Company's righful owner or Legal Representative can file for an address change to a government registry and I am not aware about what additional verification (if any) is performed by the government. We must have something to compare this process to, in order to establish what is "reasonably verified". I have no idea where the notion of 'tracability' comes from, or why that's relevant. It again seems to be anchoring on getting a certificate for the real cloudflare.com or stripe.com, which is not the discussion. We're talking about "confusing" a user (or subscriber or relying party or threat monitoring system) by suggesting that the certificates being issued are 'benign' or 'authorized'. Yes, it's clear that this is a follow-up discussion of https://groups.google.com/forum/#!searchin/mozilla.dev.security.policy/stripe%7Csort:date/mozilla.dev.security.policy/NjMmyA6MxN0/1cC9IrwjCAAJ. Sorry for the confusion. But this inaccurate data is not used in the validation process nor included in the certificates. Perhaps I didn't describe my thoughts accurately. Let me have another try using my previous example. Consider an Information Source that documents, in its practices, that they provide: 1. the Jurisdiction of Incorporation (they check official government records), 2. registry number (they check official government records), 3. the name of legal representative (they check official government records), 4. the official name of the legal entity (they check official government records), 5. street address (they check the address of a utility bill issued under the name of the legal entity), 6. telephone numbers (self-reported), 7. color of the building (self-reported). The CA evaluates this practice document and accepts information 1-5 as reliable, dismisses information 6 as non-reliable, and dismisses information 7 as irrelevant. Your argument suggests that the CA should dismiss this information source altogether, even though it clearly has acceptable and verified information for 1-5. Is that an accurate representation of your statement? Yes, I'm stating that the existence of and inclusion of 5-7 calls into question whether or not this is a reliable data source. Right, but in my example, the data source has already described -via their practices- that this is how they collect each piece of data. The CA, as a recipient of this data, can choose how much trust to lay upon each piece of information. Therefore, IMHO the CA should evaluate and use the reasonably verified information from that data source and dismiss the rest. That seems more logical to me than dismissing a data source entirely because they include "the color of the building", which is self-reported. Your parenthetical about how they check that is what the CA has the burden to demonstrate, particularly given that they have evidence that there is less-than-reliable data included. How does the competent CA ensure that the registry number is not self-reported - The information in the parenthesis would be documented in the trusted source practices and the CA would do an inquiry to check that these practices are actually implemented and followed. or that the QIIS allows it to be self-reported in the future? No one can predict the future, which is why there is a process for periodic re-evaluation. This is where the 'stopped-clock' metaphor is incredibly appropriate. Just because 1-5 happen to be right, and happen to be getting the right process, is by no means a predictor of future guarantees
Re: Concerns with Dun & Bradstreet as a QIIS
On Mon, Oct 1, 2018 at 9:21 AM Dimitris Zacharopoulos wrote: > No, this was not about the domain name but about the information displayed > to the Relying Party with the attributes included in the OV/EV Certificate > (primarily the Organization). So, I'm still uncertain if Ian's "misleading > street address" was trying to get a certificate for domain "stripe.com" > owned by "Stripe Inc." in California, or was trying to get a certificate > for "ian's domain.com" owned by "Stripe Inc." in Kentucky, as was the > previous discussions. The discussion so far indicates that it's the latter, > with the additional element that now the Street Address is also misleading. > I'm not sure the source of confusion. As the original message pointed out, this was about a Cloudflare certificate (or more aptly, two entities named Cloudflare). In both the "Stripe, Inc" and in this case, it was a domain that Ian owned and could demonstrate, for a legally incorporated entity that Ian represented. In the "Stripe, Inc" case, the information included in the certificate reflected the accurate entity - that is, the only "confusion" here was relying party confusion, while the information within the certificate was accurate. During those discussions, some suggested that it was this point - that the information was accurate, and a 'discerning' RP could distinguish between Kentucky and California - that prevented a "Stripe, Inc" cert from being problematic. This more recent "Cloudflare" issue builds upon that claim, by showing that CAs also use unreliable data sources, such that even a discerning RP may not be able to fully distinguish. In this case, Ian's attempted example was an 'off-by-one' error on a street address, while otherwise keeping all of the same information (except for serial number, since that's related to jurisdictional details). However, independent of any "name-collidey" discussion between Ian-Cloudflare and 'Real'-Cloudflare, the fact that some CAs treat D&B as a Reliable Data Source shows that unreliable data is able to be introduced into certificates. > 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 have no idea where the notion of 'tracability' comes from, or why that's relevant. It again seems to be anchoring on getting a certificate for the real cloudflare.com or stripe.com, which is not the discussion. We're talking about "confusing" a user (or subscriber or relying party or threat monitoring system) by suggesting that the certificates being issued are 'benign' or 'authorized'. > But this inaccurate data is not used in the validation process nor > included in the certificates. Perhaps I didn't describe my thoughts > accurately. Let me have another try using my previous example. Consider an > Information Source that documents, in its practices, that they provide: > > >1. the Jurisdiction of Incorporation (they check official government >records), >2. registry number (they check official government records), >3. the name of legal representative (they check official government >records), >4. the official name of the legal entity (they check official >government records), >5. street address (they check the address of a utility bill issued >under the name of the legal entity), >6. telephone numbers (self-reported), >7. color of the building (self-reported). > > The CA evaluates this practice document and accepts information 1-5 as > reliable, dismisses information 6 as non-reliable, and dismisses > information 7 as irrelevant. > > Your argument suggests that the CA should dismiss this information source > altogether, even though it clearly has acceptable and verified information > for 1-5. Is that an accurate representation of your statement? > Yes, I'm stating that the existence of and inclusion of 5-7 calls into question whether or not this is a reliable data source. Your parenthetical about how they check that is what the CA has the burden to demonstrate, particularly given that they have evidence that there is less-than-reliable data included. How does the competent CA ensure that the registry number is not self-reported - or
RE: Concerns with Dun & Bradstreet as a QIIS
Getting the whitelist figured out and workable will take a while. Disclosure could happen much faster. And I’m curious why you think it would be unauditable. It seems pretty straightforward to verify such disclosures. It think both ideas are worth considering. There’s no reason we have to do only one or the other. -Tim From: Ryan Sleevi Sent: Friday, September 28, 2018 6:35 PM To: Tim Hollebeek Cc: Dimitris Zacharopoulos ; Ian Carroll ; mozilla-dev-security-policy ; r...@sleevi.com Subject: Re: Concerns with Dun & Bradstreet as a QIIS 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 mailto:tim.holleb...@digicert.com> > 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 <mailto:dev-security-policy-boun...@lists.mozilla.org> > On > Behalf Of Ryan Sleevi via dev-security-policy > Sent: Friday, September 28, 2018 10:04 AM > To: Dimitris Zacharopoulos mailto:ji...@it.auth.gr> > > Cc: mozilla-dev-security-policy mailto:mozilla-dev-security-pol...@lists.mozilla.org> >; > Ian Carroll mailto:i...@certly.io> > > Subject: Re: Concerns with Dun & Bradstreet as a QIIS > > On Fri, Sep 28, 2018 at 1:22 AM Dimitris Zacharopoulos via dev-security-policy > <mailto:dev-security-policy@lists.mozilla.org> > 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
Re: Concerns with Dun & Bradstreet as a QIIS
On 1/10/2018 1:06 μμ, Ryan Sleevi via dev-security-policy wrote: On Mon, Oct 1, 2018 at 2:55 AM Dimitris Zacharopoulos 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. I'm just trying to understand the "attack" scenario of Ian. Domain Validation is the baseline and OV/EV builds on top of that to include verified information to the Relying Parties to assist in Trust decisions. There were suggestions in the past that the use of OV/EV validation of identity can substitute parts of Domain Validation but it's clear that this is not the case we are discussing. 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. No, this was not about the domain name but about the information displayed to the Relying Party with the attributes included in the OV/EV Certificate (primarily the Organization). So, I'm still uncertain if Ian's "misleading street address" was trying to get a certificate for domain "stripe.com" owned by "Stripe Inc." in California, or was trying to get a certificate for "ian's domain.com" owned by "Stripe Inc." in Kentucky, as was the previous discussions. The discussion so far indicates that it's the latter, with the additional element that now the Street Address is also misleading. 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? 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. But this inaccurate data is not used in the validation process nor included in the certificates. Perhaps I didn't describe my thoughts accurately. Let me have another try using my previous example.
Re: Concerns with Dun & Bradstreet as a QIIS
On Mon, Oct 1, 2018 at 2:55 AM Dimitris Zacharopoulos 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.
Re: Concerns with Dun & Bradstreet as a QIIS
On 28/9/2018 9:59 μμ, Ian Carroll via dev-security-policy wrote: On Thursday, September 27, 2018 at 10:22:05 PM UTC-7, Dimitris Zacharopoulos 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 think Ryan's reply was spot on, but I do want to clarify a couple of things. First, CAs typically make lookup requests to D&B by specifying the company's DUNS number. This means that they aren't searching for a given company name; any conflicting companies would not come up in a search. Also, I think you overestimate validation agents; Comodo actually found the real Cloudflare on another QIIS and emailed me saying they found a "similar" company, but was happy to ignore it when I gave them a valid DUNS number. I am probably not very familiar with the "Duns number" or that particular database, so I am trying to understand your goals a little better. I still don't have this picture so would you please be able to describe -in simple words- what was your ultimate goal, as "an attacker", what were you hoping to gain and how could you use this against Relying Parties? You say that the CA typically makes lookup requests to D&B by specifying the company's DUNS number. What information are they trying to validate by doing that? They normally start off by the Domain validation and try to link the name of the Registrant to an existing company. To the best of my knowledge, this number doesn't exist in Domain Registrant Information. If it did, things would be a lot simpler. Please also notice that I try to find specific flaws in the Guidelines and not look at a specific CA's validation agents. If the Guidelines adequately describe how a validation agent or a CA should perform an analysis on the quality of a Reliable Data Source or a Qualified Information Source, then at least we're good in the policy part and need to focus on why these policies are not implemented in a satisfactory way. Dimitris. 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. Since we are discussing about Data/Information Sources, the BRs define how CAs should evaluate a Data Source and declaring it "Reliable". "3.2.2.7 Data Source Accuracy Prior to using any data source as a Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification. The CA SHOULD consider the following during its evaluation: 1. The age of the information provided, 2. The frequency of updates to the information source, 3. The data provider and purpose of the data collection, 4. The public accessibility of the data availability, and 5. The relative difficulty in falsifying or altering the data. Databases maintained by the CA, its owner, or its affiliated companies do not qualify as a Reliable Data Source if the primary purpose of the database is to collect information for the purpose of fulfilling the validation requirements under this Section 3.2." The EVGs also describe how to evaluate and declare the "Qualified" status: "11.11.5. Qualified Independent Information Source A Qualified Independent Information Source (QIIS) is a regularly-updated and publicly available database that is generally recognized as a dependable source for certain information. A database qualifies as a QIIS if the CA determines that: (1) Industries other than the certificate industry rely on the database for accurate location, contact, or other information; and (2) The database provider updates its data on at least an annual basis. The CA SHALL use a documented process to check the accuracy of the database and ensure its data is acceptable, including reviewing the database provider's terms of use. The CA SHALL NOT use any data in a QIIS that the CA knows is (i) self-reported and (ii) not verified by the QIIS as accurate. Databases in which the CA or its owners or affiliated companies maintain a controlling interest, or in which any Registration Authorities or subcontractors to whom the CA has ou
Re: Concerns with Dun & Bradstreet as a QIIS
On 28/9/2018 8:04 μμ, Ryan Sleevi via dev-security-policy wrote: On Fri, Sep 28, 2018 at 1:22 AM Dimitris Zacharopoulos via dev-security-policy 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? 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. 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. 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. 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. 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. 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
Re: Concerns with Dun & Bradstreet as a QIIS
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 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 > > On > > Behalf Of Ryan Sleevi via dev-security-policy > > Sent: Friday, September 28, 2018 10:04 AM > > To: Dimitris Zacharopoulos > > Cc: mozilla-dev-security-policy > ; > > Ian Carroll > > Subject: Re: Concerns with Dun & Bradstreet as a QIIS > > > > On Fri, Sep 28, 2018 at 1:22 AM Dimitris Zacharopoulos via > dev-security-policy > > 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. > > > > >
RE: Concerns with Dun & Bradstreet as a QIIS
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 On > Behalf Of Ryan Sleevi via dev-security-policy > Sent: Friday, September 28, 2018 10:04 AM > To: Dimitris Zacharopoulos > Cc: mozilla-dev-security-policy ; > Ian Carroll > Subject: Re: Concerns with Dun & Bradstreet as a QIIS > > On Fri, Sep 28, 2018 at 1:22 AM Dimitris Zacharopoulos via dev-security-policy > 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: Concerns with Dun & Bradstreet as a QIIS
On Thursday, September 27, 2018 at 10:22:05 PM UTC-7, Dimitris Zacharopoulos 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 think Ryan's reply was spot on, but I do want to clarify a couple of things. First, CAs typically make lookup requests to D&B by specifying the company's DUNS number. This means that they aren't searching for a given company name; any conflicting companies would not come up in a search. Also, I think you overestimate validation agents; Comodo actually found the real Cloudflare on another QIIS and emailed me saying they found a "similar" company, but was happy to ignore it when I gave them a valid DUNS number. > 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. > > Since we are discussing about Data/Information Sources, the BRs define > how CAs should evaluate a Data Source and declaring it "Reliable". > > > "3.2.2.7 Data Source Accuracy > > Prior to using any data source as a Reliable Data Source, the CA SHALL > evaluate the source for its reliability, accuracy, and resistance to > alteration or falsification. The CA SHOULD consider the following during > its evaluation: > > 1. The age of the information provided, > 2. The frequency of updates to the information source, > 3. The data provider and purpose of the data collection, > 4. The public accessibility of the data availability, and > 5. The relative difficulty in falsifying or altering the data. > > Databases maintained by the CA, its owner, or its affiliated companies > do not qualify as a Reliable Data Source if the primary purpose of the > database is to collect information for the purpose of fulfilling the > validation requirements under this Section 3.2." > > The EVGs also describe how to evaluate and declare the "Qualified" status: > > > "11.11.5. Qualified Independent Information Source > > A Qualified Independent Information Source (QIIS) is a regularly-updated > and publicly available database that is generally recognized as a > dependable source for certain information. A database qualifies as a > QIIS if the CA determines that: > > (1) Industries other than the certificate industry rely on the database > for accurate location, contact, or other information; and > > (2) The database provider updates its data on at least an annual basis. > > The CA SHALL use a documented process to check the accuracy of the > database and ensure its data is acceptable, including reviewing the > database provider's terms of use. The CA SHALL NOT use any data in a > QIIS that the CA knows is (i) self-reported and (ii) not verified by the > QIIS as accurate. Databases in which the CA or its owners or affiliated > companies maintain a controlling interest, or in which any Registration > Authorities or subcontractors to whom the CA has outsourced any portion > of the vetting process (or their owners or affiliated companies) > maintain any ownership or beneficial interest, do not qualify as a QIIS." > > > 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: > > * the Jurisdicion of Incorporation (they check official government > records), > * registry number (they check official government r
Re: Concerns with Dun & Bradstreet as a QIIS
On Fri, Sep 28, 2018 at 1:22 AM Dimitris Zacharopoulos via dev-security-policy 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 upo
Re: Concerns with Dun & Bradstreet as a QIIS
(top posting for consistency) It should also be noted that OV certificates are certainly not, and EV certificates possibly not, limited to corporations in the legal sense of each jurisdiction. For starters in many jurisdictions, government entities are not technically corporations and thus not listed in the same official databases as corporations (but in separate databases of official government entities, said databases sometimes centralized, sometimes not). Secondly, non-commercial organizations (such as non-profits, professional associations etc.) are not technically corporations in all jurisdictions and there may not even be a central official database of all such entities in a Jurisdiction. Denmark is one such example, anyone has a constitutional right to create a new association and not tell anyone but the members, there is one exceptions allowing the banning of criminal associations, but it has only ever been invoked once. While there is an obscure public database of associations, most associations are not in that database. Thirdly, OV certificates can also be issued to private individuals, which belong to a different database than companies in almost every jurisdiction. Again, official central databases may or may not exist or be available for CA use, depending on the national administrative and constitutional traditions. The not-too-long-ago debate about the citizenship of a president of a major country is a great example of the lack of such a database, allegedly involving getting a special dispensation to even show a copy of paper documentation. On 28/09/2018 04:39, Tim Hollebeek wrote: I'm glad you added the smiley, because in my experience CAs have rarely, if ever, have had any discretion in such matters. Nor do we (DigiCert) particularly want to, to be honest. I prefer clear, open, and transparent validation rules that other CAs can't play games with. Whitelisting and disclosure of validation sources was an active topic of discussion at the Redmond F2F, if I'm remembering my meetings correctly. I'm surprised that more small CAs didn't support me in that effort at my previous employer, as they generally have not taken as much time or effort to find the correct sources, and instead rely upon inferior sources. If that's the direction people want to move, I'd echo Matt's concern that it will be a complex and difficult process. It's best to recall we spent a year or three trying to reach consensus about what localities existed in Taiwan and how companies could be identified there, and failed. I'm always willing to work with people on improving the baseline requirements, but there needs to be a recognition up front that this is not going to be an easy problem to solve, and people need to be willing to volunteer and roll up their sleeves and do their part in we're going to undertake such a time consuming effort. -Tim -Original Message- From: dev-security-policy On Behalf Of Ryan Sleevi via dev-security-policy Sent: Thursday, September 27, 2018 4:18 PM To: Matthew Hardeman Cc: mozilla-dev-security-policy ; Ian Carroll Subject: Re: Concerns with Dun & Bradstreet as a QIIS Yes, it would be work, but would result in consistent and reliable information, and already reflective of the fact that an EV certificate needs to identify the jurisdictionOfIncorporation and it's incorporating documents. Or are we saying that OV doesn't need to make sure it's actually a valid and legal entity, and can just display whatever information the CA feels is appropriate? ;) On Thu, Sep 27, 2018 at 6:48 PM Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: A whitelist of QGIS sounds fairly difficult. And how long would it take to adopt a new one? In some states you're going to have an authority per county. It'd be a big list. On Thu, Sep 27, 2018 at 5:35 PM, Ian Carroll via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: On Wednesday, September 26, 2018 at 6:12:22 PM UTC-7, Ryan Sleevi wrote: Thanks for raising this, Ian. The question and concern about QIIS is extremely reasonable. As discussed in past CA/Browser Forum activities, some CAs have extended the definition to treat Google Maps as a QIIS (it is not), as well as third-party WHOIS services (they’re not; that’s using a DTP). In the discussions, I proposed a comprehensive set of reforms that would wholly remedy this issue. Given that the objective of OV and EV certificates is nominally to establish a legal identity, and the legal identity is derived from State power of recognition, I proposed that only QGIS be recognized for such information. This wholly resolves differences in interpretation on suitable QIIS. However, to ensure there do not also emerge conflicting understandings of appropriate QGIS - and in particular, since the BRs and EV
Re: Concerns with Dun & Bradstreet as a QIIS
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. 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. Since we are discussing about Data/Information Sources, the BRs define how CAs should evaluate a Data Source and declaring it "Reliable". "3.2.2.7 Data Source Accuracy Prior to using any data source as a Reliable Data Source, the CA SHALL evaluate the source for its reliability, accuracy, and resistance to alteration or falsification. The CA SHOULD consider the following during its evaluation: 1. The age of the information provided, 2. The frequency of updates to the information source, 3. The data provider and purpose of the data collection, 4. The public accessibility of the data availability, and 5. The relative difficulty in falsifying or altering the data. Databases maintained by the CA, its owner, or its affiliated companies do not qualify as a Reliable Data Source if the primary purpose of the database is to collect information for the purpose of fulfilling the validation requirements under this Section 3.2." The EVGs also describe how to evaluate and declare the "Qualified" status: "11.11.5. Qualified Independent Information Source A Qualified Independent Information Source (QIIS) is a regularly-updated and publicly available database that is generally recognized as a dependable source for certain information. A database qualifies as a QIIS if the CA determines that: (1) Industries other than the certificate industry rely on the database for accurate location, contact, or other information; and (2) The database provider updates its data on at least an annual basis. The CA SHALL use a documented process to check the accuracy of the database and ensure its data is acceptable, including reviewing the database provider's terms of use. The CA SHALL NOT use any data in a QIIS that the CA knows is (i) self-reported and (ii) not verified by the QIIS as accurate. Databases in which the CA or its owners or affiliated companies maintain a controlling interest, or in which any Registration Authorities or subcontractors to whom the CA has outsourced any portion of the vetting process (or their owners or affiliated companies) maintain any ownership or beneficial interest, do not qualify as a QIIS." 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: * the Jurisdicion of Incorporation (they check official government records), * registry number (they check official government records), * the name of legal representative (they check official government records), * the official name of the legal entity (they check official government records), * street address (they check the address of a utility bill issued under the name of the legal entity), * telephone numbers (self-reported), * color of the building (self-reported), and the CA, during evaluation, might decide to accept only the first 5 as Reliable/Qualified Information as they have higher level of assurance. That would be the right thing to do. For the rest of the information, the CA should probably request additional validation information from the Applicant. Sorry for the long email, quoting requirements always does that :) Dimitris. On 27/9/2018 2:52 πμ, Ian Carroll
Re: Concerns with Dun & Bradstreet as a QIIS
On Thu, Sep 27, 2018 at 10:39 PM Tim Hollebeek wrote: > I'm glad you added the smiley, because in my experience CAs have rarely, > if ever, have had any discretion in such matters. That does not match reports from multiple former employees of various CAs. Nor do we (DigiCert) particularly want to, to be honest. I prefer clear, > open, and transparent validation rules that other CAs can't play games with. > > Whitelisting and disclosure of validation sources was an active topic of > discussion at the Redmond F2F, if I'm remembering my meetings correctly. > I'm surprised that more small CAs didn't support me in that effort at my > previous employer, as they generally have not taken as much time or effort > to find the correct sources, and instead rely upon inferior sources. > > If that's the direction people want to move, I'd echo Matt's concern that > it will be a complex and difficult process. It's best to recall we spent a > year or three trying to reach consensus about what localities existed in > Taiwan and how companies could be identified there, and failed. I think that’s conflating bad proposals with difficulty. I'm always willing to work with people on improving the baseline > requirements, but there needs to be a recognition up front that this is not > going to be an easy problem to solve, and people need to be willing to > volunteer and roll up their sleeves and do their part in we're going to > undertake such a time consuming effort. Indeed. I look forward to CAs with the day to day expertise to suggest QGIS to be added. I’m sure any CA of considerable size and scale will no doubt have a readily available list of QGIS as appropriate for their validation efforts, as part of ensuring a consistent application of their own validation policies. I can’t imagine any CA but the very smallest not already having guidance for their validation staff as to what serves as an appropriate and reliable source, as they surely wouldn’t be making it up on the fly. > > -Tim > > > -Original Message- > > From: dev-security-policy > On > > Behalf Of Ryan Sleevi via dev-security-policy > > Sent: Thursday, September 27, 2018 4:18 PM > > To: Matthew Hardeman > > Cc: mozilla-dev-security-policy < > mozilla-dev-security-pol...@lists.mozilla.org>; > > Ian Carroll > > Subject: Re: Concerns with Dun & Bradstreet as a QIIS > > > > Yes, it would be work, but would result in consistent and reliable > information, > > and already reflective of the fact that an EV certificate needs to > identify the > > jurisdictionOfIncorporation and it's incorporating documents. Or are we > saying > > that OV doesn't need to make sure it's actually a valid and legal > entity, and can > > just display whatever information the CA feels is appropriate? ;) > > > > > > On Thu, Sep 27, 2018 at 6:48 PM Matthew Hardeman via dev-security-policy > < > > dev-security-policy@lists.mozilla.org> wrote: > > > > > A whitelist of QGIS sounds fairly difficult. And how long would it > > > take to adopt a new one? > > > > > > In some states you're going to have an authority per county. It'd be > > > a big list. > > > > > > On Thu, Sep 27, 2018 at 5:35 PM, Ian Carroll via dev-security-policy < > > > dev-security-policy@lists.mozilla.org> wrote: > > > > > > > On Wednesday, September 26, 2018 at 6:12:22 PM UTC-7, Ryan Sleevi > > wrote: > > > > > Thanks for raising this, Ian. > > > > > > > > > > The question and concern about QIIS is extremely reasonable. As > > > discussed > > > > > in past CA/Browser Forum activities, some CAs have extended the > > > > definition > > > > > to treat Google Maps as a QIIS (it is not), as well as third-party > > > WHOIS > > > > > services (they’re not; that’s using a DTP). > > > > > > > > > > In the discussions, I proposed a comprehensive set of reforms that > > > would > > > > > wholly remedy this issue. Given that the objective of OV and EV > > > > > certificates is nominally to establish a legal identity, and the > > > > > legal identity is derived from State power of recognition, I > > > > > proposed that > > > only > > > > > QGIS be recognized for such information. This wholly resolves > > > differences > > > > > in interpretation on suitable QIIS. > > > > > > > > > > However, to ensure there do not also emerge co
RE: Concerns with Dun & Bradstreet as a QIIS
I'm glad you added the smiley, because in my experience CAs have rarely, if ever, have had any discretion in such matters. Nor do we (DigiCert) particularly want to, to be honest. I prefer clear, open, and transparent validation rules that other CAs can't play games with. Whitelisting and disclosure of validation sources was an active topic of discussion at the Redmond F2F, if I'm remembering my meetings correctly. I'm surprised that more small CAs didn't support me in that effort at my previous employer, as they generally have not taken as much time or effort to find the correct sources, and instead rely upon inferior sources. If that's the direction people want to move, I'd echo Matt's concern that it will be a complex and difficult process. It's best to recall we spent a year or three trying to reach consensus about what localities existed in Taiwan and how companies could be identified there, and failed. I'm always willing to work with people on improving the baseline requirements, but there needs to be a recognition up front that this is not going to be an easy problem to solve, and people need to be willing to volunteer and roll up their sleeves and do their part in we're going to undertake such a time consuming effort. -Tim > -Original Message- > From: dev-security-policy On > Behalf Of Ryan Sleevi via dev-security-policy > Sent: Thursday, September 27, 2018 4:18 PM > To: Matthew Hardeman > Cc: mozilla-dev-security-policy > ; > Ian Carroll > Subject: Re: Concerns with Dun & Bradstreet as a QIIS > > Yes, it would be work, but would result in consistent and reliable > information, > and already reflective of the fact that an EV certificate needs to identify > the > jurisdictionOfIncorporation and it's incorporating documents. Or are we saying > that OV doesn't need to make sure it's actually a valid and legal entity, and > can > just display whatever information the CA feels is appropriate? ;) > > > On Thu, Sep 27, 2018 at 6:48 PM Matthew Hardeman via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > A whitelist of QGIS sounds fairly difficult. And how long would it > > take to adopt a new one? > > > > In some states you're going to have an authority per county. It'd be > > a big list. > > > > On Thu, Sep 27, 2018 at 5:35 PM, Ian Carroll via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > > > On Wednesday, September 26, 2018 at 6:12:22 PM UTC-7, Ryan Sleevi > wrote: > > > > Thanks for raising this, Ian. > > > > > > > > The question and concern about QIIS is extremely reasonable. As > > discussed > > > > in past CA/Browser Forum activities, some CAs have extended the > > > definition > > > > to treat Google Maps as a QIIS (it is not), as well as third-party > > WHOIS > > > > services (they’re not; that’s using a DTP). > > > > > > > > In the discussions, I proposed a comprehensive set of reforms that > > would > > > > wholly remedy this issue. Given that the objective of OV and EV > > > > certificates is nominally to establish a legal identity, and the > > > > legal identity is derived from State power of recognition, I > > > > proposed that > > only > > > > QGIS be recognized for such information. This wholly resolves > > differences > > > > in interpretation on suitable QIIS. > > > > > > > > However, to ensure there do not also emerge conflicting > > > > understandings > > of > > > > appropriate QGIS - and in particular, since the BRs and EVGs > > > > recognize > > a > > > > variety of QGIS’s with variable levels of assurance relative to > > > > the information included - I further suggested that the > > > > determination of a > > > QGIS > > > > for a jurisdictional boundary should be maintained as a normative > > > whitelist > > > > that can be interoperably used and assessed against. If a given > > > > jurisdiction is not included within that whitelist, or the QGIS is > > > > not > > on > > > > it, it cannot be used. Additions to that whitelist can be > > > > maintained by > > > the > > > > Forum, based on an evaluation of the suitability of that QGIS for > > > purpose, > > > > and a consensus for adoption. > > > > > > > > This would significantly reduce the risk, while also further > > > > r
Re: Concerns with Dun & Bradstreet as a QIIS
Yes, it would be work, but would result in consistent and reliable information, and already reflective of the fact that an EV certificate needs to identify the jurisdictionOfIncorporation and it's incorporating documents. Or are we saying that OV doesn't need to make sure it's actually a valid and legal entity, and can just display whatever information the CA feels is appropriate? ;) On Thu, Sep 27, 2018 at 6:48 PM Matthew Hardeman via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > A whitelist of QGIS sounds fairly difficult. And how long would it take to > adopt a new one? > > In some states you're going to have an authority per county. It'd be a big > list. > > On Thu, Sep 27, 2018 at 5:35 PM, Ian Carroll via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > On Wednesday, September 26, 2018 at 6:12:22 PM UTC-7, Ryan Sleevi wrote: > > > Thanks for raising this, Ian. > > > > > > The question and concern about QIIS is extremely reasonable. As > discussed > > > in past CA/Browser Forum activities, some CAs have extended the > > definition > > > to treat Google Maps as a QIIS (it is not), as well as third-party > WHOIS > > > services (they’re not; that’s using a DTP). > > > > > > In the discussions, I proposed a comprehensive set of reforms that > would > > > wholly remedy this issue. Given that the objective of OV and EV > > > certificates is nominally to establish a legal identity, and the legal > > > identity is derived from State power of recognition, I proposed that > only > > > QGIS be recognized for such information. This wholly resolves > differences > > > in interpretation on suitable QIIS. > > > > > > However, to ensure there do not also emerge conflicting understandings > of > > > appropriate QGIS - and in particular, since the BRs and EVGs recognize > a > > > variety of QGIS’s with variable levels of assurance relative to the > > > information included - I further suggested that the determination of a > > QGIS > > > for a jurisdictional boundary should be maintained as a normative > > whitelist > > > that can be interoperably used and assessed against. If a given > > > jurisdiction is not included within that whitelist, or the QGIS is not > on > > > it, it cannot be used. Additions to that whitelist can be maintained by > > the > > > Forum, based on an evaluation of the suitability of that QGIS for > > purpose, > > > and a consensus for adoption. > > > > > > This would significantly reduce the risk, while also further reducing > > > ambiguities that have arisen from some CAs attempting to argue that > > > non-employees of the CA or QGIS, but which act as intermediaries on > > behalf > > > of the CA to the QGIS, are not functionally and formally DTPs and this > > > subject to the assessment requirements of DTPs. This ambiguity is being > > > exploited in ways that can allow a CA to nominally say it checked a > QGIS, > > > but is relying on the word of a third-party, and with no assurance of > the > > > system security of that third party. > > > > > > Do you think such a proposal would wholly address your concern? > > > > I think I'll always agree with removing intermediaries from the > validation > > process. Outside of practical concerns, a whitelist of QGIS entities > sounds > > like a good idea. > > > > I would wonder what the replacement for D&B is in the United States. You > > can normally get an address for a company from a QGIS but not (from the > > states I've seen) a phone number for callback verification. > > ___ > > dev-security-policy mailing list > > dev-security-policy@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-security-policy > > > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Concerns with Dun & Bradstreet as a QIIS
A whitelist of QGIS sounds fairly difficult. And how long would it take to adopt a new one? In some states you're going to have an authority per county. It'd be a big list. On Thu, Sep 27, 2018 at 5:35 PM, Ian Carroll via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On Wednesday, September 26, 2018 at 6:12:22 PM UTC-7, Ryan Sleevi wrote: > > Thanks for raising this, Ian. > > > > The question and concern about QIIS is extremely reasonable. As discussed > > in past CA/Browser Forum activities, some CAs have extended the > definition > > to treat Google Maps as a QIIS (it is not), as well as third-party WHOIS > > services (they’re not; that’s using a DTP). > > > > In the discussions, I proposed a comprehensive set of reforms that would > > wholly remedy this issue. Given that the objective of OV and EV > > certificates is nominally to establish a legal identity, and the legal > > identity is derived from State power of recognition, I proposed that only > > QGIS be recognized for such information. This wholly resolves differences > > in interpretation on suitable QIIS. > > > > However, to ensure there do not also emerge conflicting understandings of > > appropriate QGIS - and in particular, since the BRs and EVGs recognize a > > variety of QGIS’s with variable levels of assurance relative to the > > information included - I further suggested that the determination of a > QGIS > > for a jurisdictional boundary should be maintained as a normative > whitelist > > that can be interoperably used and assessed against. If a given > > jurisdiction is not included within that whitelist, or the QGIS is not on > > it, it cannot be used. Additions to that whitelist can be maintained by > the > > Forum, based on an evaluation of the suitability of that QGIS for > purpose, > > and a consensus for adoption. > > > > This would significantly reduce the risk, while also further reducing > > ambiguities that have arisen from some CAs attempting to argue that > > non-employees of the CA or QGIS, but which act as intermediaries on > behalf > > of the CA to the QGIS, are not functionally and formally DTPs and this > > subject to the assessment requirements of DTPs. This ambiguity is being > > exploited in ways that can allow a CA to nominally say it checked a QGIS, > > but is relying on the word of a third-party, and with no assurance of the > > system security of that third party. > > > > Do you think such a proposal would wholly address your concern? > > I think I'll always agree with removing intermediaries from the validation > process. Outside of practical concerns, a whitelist of QGIS entities sounds > like a good idea. > > I would wonder what the replacement for D&B is in the United States. You > can normally get an address for a company from a QGIS but not (from the > states I've seen) a phone number for callback verification. > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-security-policy > ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Concerns with Dun & Bradstreet as a QIIS
On Wednesday, September 26, 2018 at 6:12:22 PM UTC-7, Ryan Sleevi wrote: > Thanks for raising this, Ian. > > The question and concern about QIIS is extremely reasonable. As discussed > in past CA/Browser Forum activities, some CAs have extended the definition > to treat Google Maps as a QIIS (it is not), as well as third-party WHOIS > services (they’re not; that’s using a DTP). > > In the discussions, I proposed a comprehensive set of reforms that would > wholly remedy this issue. Given that the objective of OV and EV > certificates is nominally to establish a legal identity, and the legal > identity is derived from State power of recognition, I proposed that only > QGIS be recognized for such information. This wholly resolves differences > in interpretation on suitable QIIS. > > However, to ensure there do not also emerge conflicting understandings of > appropriate QGIS - and in particular, since the BRs and EVGs recognize a > variety of QGIS’s with variable levels of assurance relative to the > information included - I further suggested that the determination of a QGIS > for a jurisdictional boundary should be maintained as a normative whitelist > that can be interoperably used and assessed against. If a given > jurisdiction is not included within that whitelist, or the QGIS is not on > it, it cannot be used. Additions to that whitelist can be maintained by the > Forum, based on an evaluation of the suitability of that QGIS for purpose, > and a consensus for adoption. > > This would significantly reduce the risk, while also further reducing > ambiguities that have arisen from some CAs attempting to argue that > non-employees of the CA or QGIS, but which act as intermediaries on behalf > of the CA to the QGIS, are not functionally and formally DTPs and this > subject to the assessment requirements of DTPs. This ambiguity is being > exploited in ways that can allow a CA to nominally say it checked a QGIS, > but is relying on the word of a third-party, and with no assurance of the > system security of that third party. > > Do you think such a proposal would wholly address your concern? I think I'll always agree with removing intermediaries from the validation process. Outside of practical concerns, a whitelist of QGIS entities sounds like a good idea. I would wonder what the replacement for D&B is in the United States. You can normally get an address for a company from a QGIS but not (from the states I've seen) a phone number for callback verification. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Concerns with Dun & Bradstreet as a QIIS
> The question and concern about QIIS is extremely reasonable. As discussed in > past CA/Browser Forum activities, some CAs have extended the definition to > treat Google Maps as a QIIS (it is not), as well as third-party WHOIS services > (they’re not; that’s using a DTP). It's worth noting that the BRs currently say "WHOIS: Information retrieved directly from the Domain Name Registrar or registry operator ..." so I'm not sure using a DTP is actually permitted. Though I don't think we've discussed that point since the language was added. > In the discussions, I proposed a comprehensive set of reforms that would > wholly remedy this issue. Given that the objective of OV and EV certificates > is > nominally to establish a legal identity, and the legal identity is derived > from > State power of recognition, I proposed that only QGIS be recognized for such > information. This wholly resolves differences in interpretation on suitable > QIIS. We agree with this. -Tim smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: Concerns with Dun & Bradstreet as a QIIS
Thanks for raising this, Ian. The question and concern about QIIS is extremely reasonable. As discussed in past CA/Browser Forum activities, some CAs have extended the definition to treat Google Maps as a QIIS (it is not), as well as third-party WHOIS services (they’re not; that’s using a DTP). In the discussions, I proposed a comprehensive set of reforms that would wholly remedy this issue. Given that the objective of OV and EV certificates is nominally to establish a legal identity, and the legal identity is derived from State power of recognition, I proposed that only QGIS be recognized for such information. This wholly resolves differences in interpretation on suitable QIIS. However, to ensure there do not also emerge conflicting understandings of appropriate QGIS - and in particular, since the BRs and EVGs recognize a variety of QGIS’s with variable levels of assurance relative to the information included - I further suggested that the determination of a QGIS for a jurisdictional boundary should be maintained as a normative whitelist that can be interoperably used and assessed against. If a given jurisdiction is not included within that whitelist, or the QGIS is not on it, it cannot be used. Additions to that whitelist can be maintained by the Forum, based on an evaluation of the suitability of that QGIS for purpose, and a consensus for adoption. This would significantly reduce the risk, while also further reducing ambiguities that have arisen from some CAs attempting to argue that non-employees of the CA or QGIS, but which act as intermediaries on behalf of the CA to the QGIS, are not functionally and formally DTPs and this subject to the assessment requirements of DTPs. This ambiguity is being exploited in ways that can allow a CA to nominally say it checked a QGIS, but is relying on the word of a third-party, and with no assurance of the system security of that third party. Do you think such a proposal would wholly address your concern? ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
RE: Concerns with Dun & Bradstreet as a QIIS
There have been previous discussions about this very issue at CA/Browser Forum Validation Working Group meetings (see also draft Ballot 225). I think it is widely recognized that the rules around QIISs are far too weak and in need of improvement. I actually recently asked Kirk to add an item on the agenda for the upcoming Face to Face meeting in Shanghai where we intend to push for the elimination of the ability to rely upon unofficial information sources, especially Dun & Bradstreet, for the reasons you cite. It isn't a reliable information source. -Tim > -Original Message- > From: dev-security-policy On > Behalf Of Ian Carroll via dev-security-policy > Sent: Wednesday, September 26, 2018 4:53 PM > To: mozilla-dev-security-pol...@lists.mozilla.org > Subject: Concerns with Dun & Bradstreet as a QIIS > > Hi, > > In April and May of this year, I attempted to change the address listed in Dun > & Bradstreet of my (Kentucky-incorporated) company "Stripe, Inc" to an > address in Toledo, Ohio that did not exist (185 Berry Street Toledo Ohio). I was > wondering the extent of validation Dun & Bradstreet would do on the data. > > To my surprise, they accepted my change request a couple days later. This is > concerning, of course, because D&B is a QIIS backing most EV certificate > requests in the United States. > > After this worked, I realized this was probably worth exploring more, so I took > my "Cloudflare, Inc" company (also incorporated in Kentucky) and requested > that Dun & Bradstreet change its address to "102 Townsend St San Francisco > CA". You might notice that this is the same address as the real Cloudflare, but > with the street number incremented by one. > > D&B accepted that change request as well. This meant I controlled a DUNS > number that would resolve to a very similar address to CF, with my phone > number on it. > > I ordered two EV certificates from Comodo (order #s 136665865 and > 141269115) with these fake DUNS numbers. I successfully completed the > validation and callback process for the Cloudflare order, and Comodo was > about to issue the certificate, but both of my orders were silently deleted > before they were about to be issued. > > Comodo would not give me any information about why they (silently) rejected > my orders, but Dun & Bradstreet banned my account shortly after, so it is safe > to say they reported me after they realized something went wrong. > > I think this is a strong indictment of D&B as a QIIS. The definition of a QIIS, in > my opinion, is incredibly lax, but "which is generally recognized as a > dependable source of such information" is hard to meet here. > > I am also, frankly, annoyed that Comodo seems to have silently discovered > that D&B was unreliable and then ignored it without reporting it further. I > myself have been meaning to send this for a while, given I did this in May, but > various things have made it difficult for me to find the time. > > Let me know if I can provide any further information. > ___ > dev-security-policy mailing list > dev-security-policy@lists.mozilla.org > https://clicktime.symantec.com/a/1/c3r2Ter8o50ppUH1pIlJlwoc7bmoCICI5nzl > tycPf2k=?d=5ni4BvuKRPoeQ16JRlwwiqHkXFkBGUNLawHjFKnYSsf_1- > W_uIoVE7PpGy6jmRBVcHjzciQQk9w61dUl2ViqRl9bL4r7h1J9S9DnsSgtX6UGfDf > Rw3t__-hkOfmQMNa6AXM-enLMWQTxBynJj7o6Tlz6Akz4f- > aW0KhOd4ZuAiOOxDs_WV7pO1wwY7wj9jCQ6GrgFJ7Zp3yZiiRnOGTKdbrRkzd9 > r7KzcqXr_4GkkZJ2Z78_8- > Jmhw1XhrraBB_UID6gaAWdIrWxgcU4BJ4fj_Y5rGvyNW8yslAxFPRAz74O5WScx > _QY7Z1ADHevtAXEsTB9FzRWQunaRP-OX8BfZHBtyGCEeZbV8b_s- > eJ79m1giXYdCU-v98Yt1xsAk9pA1A- > ythvQuBnksHG3tYf2auSXR0dbNaCDK46t6yIVXAQ%3D&u=https%3A%2F%2Flist > s.mozilla.org%2Flistinfo%2Fdev-security-policy smime.p7s Description: S/MIME cryptographic signature ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Concerns with Dun & Bradstreet as a QIIS
Hi, In April and May of this year, I attempted to change the address listed in Dun & Bradstreet of my (Kentucky-incorporated) company "Stripe, Inc" to an address in Toledo, Ohio that did not exist (185 Berry Street Toledo Ohio). I was wondering the extent of validation Dun & Bradstreet would do on the data. To my surprise, they accepted my change request a couple days later. This is concerning, of course, because D&B is a QIIS backing most EV certificate requests in the United States. After this worked, I realized this was probably worth exploring more, so I took my "Cloudflare, Inc" company (also incorporated in Kentucky) and requested that Dun & Bradstreet change its address to "102 Townsend St San Francisco CA". You might notice that this is the same address as the real Cloudflare, but with the street number incremented by one. D&B accepted that change request as well. This meant I controlled a DUNS number that would resolve to a very similar address to CF, with my phone number on it. I ordered two EV certificates from Comodo (order #s 136665865 and 141269115) with these fake DUNS numbers. I successfully completed the validation and callback process for the Cloudflare order, and Comodo was about to issue the certificate, but both of my orders were silently deleted before they were about to be issued. Comodo would not give me any information about why they (silently) rejected my orders, but Dun & Bradstreet banned my account shortly after, so it is safe to say they reported me after they realized something went wrong. I think this is a strong indictment of D&B as a QIIS. The definition of a QIIS, in my opinion, is incredibly lax, but "which is generally recognized as a dependable source of such information" is hard to meet here. I am also, frankly, annoyed that Comodo seems to have silently discovered that D&B was unreliable and then ignored it without reporting it further. I myself have been meaning to send this for a while, given I did this in May, but various things have made it difficult for me to find the time. Let me know if I can provide any further information. ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
