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 via dev-security-policy wrote:
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
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
