Concerns with Dun & Bradstreet as a QIIS

[Ian Carroll]

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.

[Tim Hollebeek]

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

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@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

[Ryan Sleevi]

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?

[Tim Hollebeek]

> 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

[Ian Carroll]

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.

[Matthew Hardeman]

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-secur...@lists.mozilla.org> wrote:

> On Wednesday, September 26, 2018 at 6:12:22 PM UTC-7, Ryan Sleevi wrote:

> 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-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy
>

[Ryan Sleevi]

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-secur...@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-secur...@lists.mozilla.org> wrote:
>
> > On Wednesday, September 26, 2018 at 6:12:22 PM UTC-7, Ryan Sleevi wrote:

[Tim Hollebeek]

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 <dev-security-...@lists.mozilla.org> On

> Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Thursday, September 27, 2018 4:18 PM
> To: Matthew Hardeman <mhar...@gmail.com>
> Cc: mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>;
> Ian Carroll <i...@certly.io>
> 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-secur...@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-secur...@lists.mozilla.org> wrote:
> >
> > > On Wednesday, September 26, 2018 at 6:12:22 PM UTC-7, Ryan Sleevi
> wrote:

> > > 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-secur...@lists.mozilla.org

> > > https://clicktime.symantec.com/a/1/y-
> dE77yYyDdE_vODZUczVhOtZuTYGGpGY
> > > 4Ii6XyCtys=?d=xM_nZuwA5sJLRzEZ-5hDj-JdWPtyAlcZZSlbxRTAHy-P-
> XNq9xx3jZ
> > > 8iYY-JYfKe4RiDTuQy3-3XiUBrmB3w4qsPdn5Qrf-
> CMBxWOl1qZBE7XLTbJKqROFOm98
> > >
> igoWWqCcSEnWeNlX7a0Wh3pE05MZ91kVuZWWuarXbE3EoGnfZLEObXJJUmi
> Olntz70gG
> > > WBYHCIwVzMUQhPCZEPWy12x-
> SkAk1M0sZt5O73AtmpMNz6Z08r6LQtV1y2hfVDK3HMhw
> > >
> EJHdoBlayDtyh1eyIn8SYuMUmODq4R6U5XRY7QIXzNXVe6q7QGPNFNZXiL4zLL
> YjPDgs
> > >
> eJ_9XC01RMMGPoIPYZz_eKhdDLAeohYGycl29w2LIIhVNjTxOHRvnm_aL9Dydyk
> KTB-s
> > > a9OWGIW7-kCGpvY6utRiMz6-h2bcQC-
> 1RofZxCREXLpgDv07vLGgyXoQ%3D%3D&u=htt
> > > ps%3A%2F%2Flists.mozilla.org%2Flistinfo%2Fdev-security-policy

> > >
> > _______________________________________________
> > dev-security-policy mailing list
> > dev-secur...@lists.mozilla.org

> > https://clicktime.symantec.com/a/1/y-
> dE77yYyDdE_vODZUczVhOtZuTYGGpGY4I
> > i6XyCtys=?d=xM_nZuwA5sJLRzEZ-5hDj-JdWPtyAlcZZSlbxRTAHy-P-
> XNq9xx3jZ8iYY
> > -JYfKe4RiDTuQy3-3XiUBrmB3w4qsPdn5Qrf-
> CMBxWOl1qZBE7XLTbJKqROFOm98igoWWq
> >
> CcSEnWeNlX7a0Wh3pE05MZ91kVuZWWuarXbE3EoGnfZLEObXJJUmiOlntz70g
> GWBYHCIwV
> > zMUQhPCZEPWy12x-
> SkAk1M0sZt5O73AtmpMNz6Z08r6LQtV1y2hfVDK3HMhwEJHdoBlayD
> >
> tyh1eyIn8SYuMUmODq4R6U5XRY7QIXzNXVe6q7QGPNFNZXiL4zLLYjPDgseJ_9X
> C01RMMG
> > PoIPYZz_eKhdDLAeohYGycl29w2LIIhVNjTxOHRvnm_aL9DydykKTB-
> sa9OWGIW7-kCGpv
> > Y6utRiMz6-h2bcQC-
> 1RofZxCREXLpgDv07vLGgyXoQ%3D%3D&u=https%3A%2F%2Flists
> > .mozilla.org%2Flistinfo%2Fdev-security-policy

> >
> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://clicktime.symantec.com/a/1/y-
> dE77yYyDdE_vODZUczVhOtZuTYGGpGY4Ii6XyCtys=?d=xM_nZuwA5sJLRzEZ-
> 5hDj-JdWPtyAlcZZSlbxRTAHy-P-XNq9xx3jZ8iYY-JYfKe4RiDTuQy3-
> 3XiUBrmB3w4qsPdn5Qrf-
> CMBxWOl1qZBE7XLTbJKqROFOm98igoWWqCcSEnWeNlX7a0Wh3pE05MZ91k
> VuZWWuarXbE3EoGnfZLEObXJJUmiOlntz70gGWBYHCIwVzMUQhPCZEPWy12x
> -
> SkAk1M0sZt5O73AtmpMNz6Z08r6LQtV1y2hfVDK3HMhwEJHdoBlayDtyh1eyIn
> 8SYuMUmODq4R6U5XRY7QIXzNXVe6q7QGPNFNZXiL4zLLYjPDgseJ_9XC01RM
> MGPoIPYZz_eKhdDLAeohYGycl29w2LIIhVNjTxOHRvnm_aL9DydykKTB-
> sa9OWGIW7-kCGpvY6utRiMz6-h2bcQC-
> 1RofZxCREXLpgDv07vLGgyXoQ%3D%3D&u=https%3A%2F%2Flists.mozilla.org
> %2Flistinfo%2Fdev-security-policy

[Ryan Sleevi]

On Thu, Sep 27, 2018 at 10:39 PM Tim Hollebeek <tim.ho...@digicert.com>
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.

[Dimitris Zacharopoulos]

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 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
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy

[Jakob Bohm]

(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.

Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S. https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark. Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded

[Ryan Sleevi]

On Fri, Sep 28, 2018 at 1:22 AM Dimitris Zacharopoulos via
dev-security-policy <dev-secur...@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 accept whatever address you tell them because:
>
> 1. They have no reason to believe that you will lie to them (they know
> who you are and in some Jurisdictions you might be prosecuted for
> lying to the government)

> 2. No foreseeable harm to others could be done if you misrepresent your
> own address.
>

Then they are not Reliable nor QIISes. Full stop.

> In my understanding, this is the process each CA must perform to
> evaluate every Data Source before granting them the "Reliable" or
> "Qualified" status. Self-reported information without any supporting
> evidence is clearly not acceptable. I have not evaluated this database
> that you mention but if they accept self-reporting for "Street Address"
> and don't perform any additional verification (like asking you for a
> utility bill or cross-referencing it with a government database), then
> the "Street Address" information is unreliable and the CA's evaluation
> process should catch that.
>
> That doesn't mean that the rest of the information is also unreliable.
> For example, an Information Source might describe in their documentation
> practices how they verify each piece of information, for example:
>

I disagree with this assessment, and I think it's precisely why greater
restriction is needed on the flexibility of CAs to make such
interpretations. I understand the point you're trying to make - why throw
the baby out with the bathwater - but to its use within the EVGs and the
BRs, such structural issues throw into fundamental question the status as a
RDS or QIIS.

As you highlight, this is an assessment that each CA makes, according to
its own processes and skills, and based on their own understanding.
Auditors, which while required to have professional understanding of the
relevant standards but are by no means omniscient nor experts, then also
review these processes. Thus, we can easily end up in a situation where CA
A determines that Foo is an RDS and QIIS for (Address, Serial Number),
while CA B determines that Foo is an RDS and QIIS only for (Serial Number).

For an adversarial model, however, the strength of CA B's understanding and
recognition that Foo is not suitable as a QIIS for Address is irrelevant,
as an adversary needs only obtain a certificate from CA A instead. While
I'm sure CA B would love to market and crow about their excellence in the
market for recognizing that Foo was not a QIIS for Address, to the end
user, browser, and relying party, the fact that CA B deserves a cookie and
a pat on the back is irrelevant.

This is because the goal of a given root program is to ensure a
consistently operated PKI with a consistent degree of assurance. That CA A
accepts Foo as a QIIS and CA B does not, because they both participate in
the same PKI (namely, the browser's root program), the levels of assurance
are not equal to the expectations of the policy. One model of approaching
this is to try to outsource that lack of assurance to the relying party -
for example, telling them that "CA A shouldn't be relied upon" or "CA B is
more trustworthy" - but for the Web, that's a fundamentally failed model
full of user-hostility. The other approach is to establish more consistent
criteria to assess CA A and CA B against, to reduce the divergence in
assurance - which is where a whitelist comes from.

[Ian Carroll]

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.

[Tim Hollebeek]

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 <dev-security-...@lists.mozilla.org>
On
> Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Friday, September 28, 2018 10:04 AM
> To: Dimitris Zacharopoulos <ji...@it.auth.gr>
> Cc: mozilla-dev-security-policy
<mozilla-dev-s...@lists.mozilla.org>;
> Ian Carroll <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

> <dev-secur...@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 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:
> >
>

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://clicktime.symantec.com/a/1/YhGZos1avY3eKvMWKYlmLu1ii28BaqX5h
> enyGbAJ5EY=?d=qYFp5yYkROrafPELVxZ46o5rfBVUzBR1PCFPo4qD5MguYYTrSY
> My6BxhqJFYwXl1DE7irkYWqyBqAhPuIWyDnqqdby9NLQaPW2qd7vmFFVSr1ho
> LCdp-l4LtbLHD8JeP3Ac9km0ARlqmleBd__LH7NYWCsRGWT2YNYWUVM-
> CUIBVDC8Kb0fuERJWO9tJv9qeAaccg_uBko09aMAW0uAgPIxRsrLuDrHQttxima
> UeizHsrnLnK5hghSjCdHJlQlZV9PYYF6zv_eiIE5au-
> qiI3aLCRhoB5J86pb9_WZQUHKZo8vKEjQ5swiyLRct5TOAdbvlmIH7KztTEgJrndI
> mm6lNGbPXr2LTyldgjBd7gnVU6fU8Aau46fKFSNWnsueNVprp2Qka8Hc7KNi7oJ
> 3R5GIsF0yFMlL5Oje00H9b7p2-
> NasIMD_A5A8t_0pQGrB85yg%3D%3D&u=https%3A%2F%2Flists.mozilla.org%2
> Flistinfo%2Fdev-security-policy

[Ryan Sleevi]

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 <tim.ho...@digicert.com>
wrote:

[Dimitris Zacharopoulos]

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.

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.

> This is because the goal of a given root program is to ensure a
> consistently operated PKI with a consistent degree of assurance. That CA A
> accepts Foo as a QIIS and CA B does not, because they both participate in
> the same PKI (namely, the browser's root program), the levels of assurance
> are not equal to the expectations of the policy. One model of approaching
> this is to try to outsource that lack of assurance to the relying party -
> for example, telling them that "CA A shouldn't be relied upon" or "CA B is
> more trustworthy" - but for the Web, that's a fundamentally failed model
> full of user-hostility. The other approach is to establish more consistent
> criteria to assess CA A and CA B against, to reduce the divergence in
> assurance - which is where a whitelist comes from.

CAs are required to comply with very complicated standards and these
standards describe best practices on how to evaluate and re-evaluate
information sources.

If CA A trusted the "street address" from a DS, used this information to
be included in Certificates and later during re-evaluation discovered
that this particular piece of information is unreliable, I would expect
this to be treated as an incident according to the current standards.
The CA would have to create a plan to mitigate this problem. Again, this
depends on the CA's decisions how to mitigate the problem. Others would
revoke all the affected certificates immediately, others would
re-evaluate the "street address" information using a different reliable
source and revoke the Certificates they were unable to re-verify, others
would do nothing. It is impossible to cover all possible cases and
require equal treatment for incidents.

I fully support a white-list of RDS/QIS with global acceptance and
collective scrutiny but even these lists need to be re-evaluated
periodically as required by our standards. Perhaps a "global black-list"
might be setup for certain cases of misbehavior like the one described
above. However, this white-list should not be the only one allowed  to
be used and national jurisdiction databases (company registries) should
also be allowed provided they are adequately evaluated by the CA
according to our standards.
I also support the idea of describing which information is evaluated as
"reliable" from a particular source and not completely dismiss a source
if they describe in their practices that they accept "some other"
irrelevant-to-the-ca information as self-reported.

It is a very challenging goal, especially because there are so many
different jurisdictions from which to collect reliable information. As a
more realistic goal, perhaps we could describe the ideal data source
evaluation and periodic re-evaluation process more explicitly in the
Guidelines, with clear and auditable criteria.


Dimitris.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy

[Dimitris Zacharopoulos]

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.

[Ryan Sleevi]

On Mon, Oct 1, 2018 at 2:55 AM Dimitris Zacharopoulos <ji...@it.auth.gr>
wrote:

> Perhaps I am confusing different past discussions. If I recall correctly,
> in previous discussions we described the case where an attacker tries to
> get a certificate for a company "Example Inc." with domain "example.com".
> This domain has a domain Registrant Address as "123 Example Street".
>
> The attacker registers a company with the same name "Example Inc." in a
> different jurisdiction, with address "123 Example Street" and a different
> (attacker's) phone number. How is the attacker able to get a certificate
> for example.com? That would be a real "attack" scenario.
>

Yes, you are confusing things, as I would have thought this would be a
'simple' discussion. Perhaps this confusion comes from only thinking the
domain name matters in making an 'attack'. If that's the case, we can do
away with EV and OV entirely, because they do not provide value to that
domain validation. Alternatively, if we say that information is relevant,
then the ability to spoof any of that information also constitutes an
'attack' - to have the information for one organization presented in a
different (logical, legal) organization's associated information.

> Unless this topic comes as a follow-up to the previous discussion of
> displaying the "Stripe Inc." information to Relying Parties, with the
> additional similarity in Street Address and not just the name of the
> Organization. If I recall correctly, that second "Stripe Inc." was not a
> "fake" entity but a "real" entity that was properly registered in some
> Jurisdiction. This doesn't seem to be the same attack scenario as getting a
> certificate for a Domain for which you are not the owner nor control, but a
> way to confuse Relying Parties. Certainly, in case of fraud, this leaves a
> lot more evidence for the authorities to trail back to a source, than for a
> case without Organization information.
>

This also seems to be fixing on the domain name, but I have no idea why
you've chosen that as the fixation, as the discussion to date doesn't
involve that. I don't think it's your intent, but it sounds like you're
saying "It's better for CAs to put inaccurate and misleading information in
certificates, because at least then it's there" - which surely makes no
sense.

> But they do have some Reliable and Qualified Information according to our
> standards (for example registry number, legal representative, company
> name). If a CA uses only this information from that source, why shouldn't
> it be considered reliable? We all need to consider the fact that CAs use
> tools to do their validation job effectively and efficiently. These tools
> are evaluated continuously. Complete dismissal of tools must be justified
> in a very concrete way.
>

No, they are not Reliable Data Sources. Using unreliable data sources,
under the motto that "even a stopped clock is right twice a day", requires
clear and concrete justification. The burden is on the CA to demonstrate
the data sources reliability. If there is any reason to suspect that a
Reliable Data Source contains inaccurate data, you should not be using it -
for any data.

> I would accept your conclusion for an Information Source that claimed, in
> their practices, that they verify some information against a secondary
> government database and the CA gets evidence that they don't actually do
> that. This means that the rest of the "claimed as verified" information is
> now questionable. This is very much similar to the Browsers checking for
> misbehavior on CAs where they claim certain practices in their CP/CPS and
> don't actually implement them. That would be a case where the CA might
> decide to completely distrust that Information Source.
>
> I hope you can see the difference.
>

I hope you can understand that this is not an apt or accurate comparison.
An organization that lacks a process, which is the case for unreliable
data, is no different than an organization that declares a process but does
not follow it.

> I remember this argument being supported in the past and although I used
> to agree to it, with the recent developments and CA disqualifications, I
> support the opposite. That is, Subscribers start to choose their CA more
> carefully and pay attention to the trust, reputation and practices, because
> of the risk of getting their Certificates challenged, revoked or the CA
> distrusted.
>

So you believe it's in best interests of Subscribers to have CAs
distrusted, certificates challenged and revoked, and for relying parties to
constantly call into question the certificates they encounter? And that
this is somehow better than consistently applied and executed validation
processes? I wish I could share your "Mad Max" level of optimism, but it
also fails to understand that we're not talking about Subscriber selection,
we're talking about adversarial models. The weakest link matters, not
"market reputation", as much as some CAs would like to believe.

> CAs are required to comply with very complicated standards and these
> standards describe best practices on how to evaluate and re-evaluate
> information sources.
>
> If CA A trusted the "street address" from a DS, used this information to
> be included in Certificates and later during re-evaluation discovered that
> this particular piece of information is unreliable, I would expect this to
> be treated as an incident according to the current standards. The CA would
> have to create a plan to mitigate this problem. Again, this depends on the
> CA's decisions how to mitigate the problem. Others would revoke all the
> affected certificates immediately, others would re-evaluate the "street
> address" information using a different reliable source and revoke the
> Certificates they were unable to re-verify, others would do nothing. It is
> impossible to cover all possible cases and require equal treatment for
> incidents.
>

Funny enough, that subjectivity you just described is not permitted of CAs,
and for good reason. Every one of those certificates needs to be revoked,
per 4.9.1.1 of the BRs. The CA has also material misstated its warranty for
these certificates, per 9.6.1.

> I fully support a white-list of RDS/QIS with global acceptance and
> collective scrutiny but even these lists need to be re-evaluated
> periodically as required by our standards. Perhaps a "global black-list"
> might be setup for certain cases of misbehavior like the one described
> above. However, this white-list should not be the only one allowed to be
> used and national jurisdiction databases (company registries) should also
> be allowed provided they are adequately evaluated by the CA according to
> our standards.
>

As anyone with any security background can tell you, whitelists address the
objectives where blacklists address the appearances.

If you believe that there are national jurisdictional databases, they can
be added to the whitelist. Indeed, the entire point would be to ensure
that, for the appropriate jurisdictional boundary, there's a clear
indication as to appropriate data sources. Then, there is no need for CA
discretion - or indiscretion.

> I also support the idea of describing which information is evaluated as
> "reliable" from a particular source and not completely dismiss a source if
> they describe in their practices that they accept "some other"
> irrelevant-to-the-ca information as self-reported.
>

So you would also see the whitelist broken down by jurisdiction and by data
source. Unless and until there is a whitelist, there is no safe way to
permit that usage you're describing.

> It is a very challenging goal, especially because there are so many
> different jurisdictions from which to collect reliable information. As a
> more realistic goal, perhaps we could describe the ideal data source
> evaluation and periodic re-evaluation process more explicitly in the
> Guidelines, with clear and auditable criteria.
>

We're not short of describing expectations. We're short of CAs meeting
expectations. And as I said, for an adversarial model, it does not matter
what the best or 'most' do, it only matters what a single one permits. As
such, a solution to "double down" on language that allows a CA to
interpretive dance their way out of the objectives is not valuable, nor is
any solution that relies on auditor review. Indeed, the main argument for
'auditable' criteria would be so that CAs could disguise their shady
practices through a lack of transparent reporting, rather than the
objective of this thread, which is to improve it through transparency.

[Dimitris Zacharopoulos]

On 1/10/2018 1:06 μμ, Ryan Sleevi via dev-security-policy wrote:
> On Mon, Oct 1, 2018 at 2:55 AM Dimitris Zacharopoulos <ji...@it.auth.gr>
> 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. 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?

>
>> 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.

But in my example, they don't lack a process, they clearly tell you
beforehand that the color of the building is self-reported. They do have
a process and it's the CA's call (or whoever uses this information) to
accept and use this information or not. I see a big difference if an
organization declares a process and then doesn't follow it, compared to
an organization that has a process, let's you know beforehand that some
piece of information is self-reported and you can judge to use this
particular piece of information or not. The latter is consistent and the
former is not.

>
>> 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.

Again, I might have described my thoughts unclearly. I was only trying
to say that Subscribers now pay more attention to the CA they chose than
they did before. They may not choose a "loose" or "weak" CA that easily
because of the risks associated with that decision.

>
>> CAs are required to comply with very complicated standards and these
>> standards describe best practices on how to evaluate and re-evaluate
>> information sources.
>>
>> If CA A trusted the "street address" from a DS, used this information to
>> be included in Certificates and later during re-evaluation discovered that
>> this particular piece of information is unreliable, I would expect this to
>> be treated as an incident according to the current standards. The CA would
>> have to create a plan to mitigate this problem. Again, this depends on the
>> CA's decisions how to mitigate the problem. Others would revoke all the
>> affected certificates immediately, others would re-evaluate the "street
>> address" information using a different reliable source and revoke the
>> Certificates they were unable to re-verify, others would do nothing. It is
>> impossible to cover all possible cases and require equal treatment for
>> incidents.
>>
> Funny enough, that subjectivity you just described is not permitted of CAs,
> and for good reason. Every one of those certificates needs to be revoked,
> per 4.9.1.1 of the BRs. The CA has also material misstated its warranty for
> these certificates, per 9.6.1.

Yet we've seen this being exercised before and definitely in violation
of the 24 hour window. The main issue that we have seen some CAs
struggle with and explain in Incident Reports is that this information
might actually be proven to be accurate and can be re-validated without
causing interruptions for Subscribers and Relying Parties.

>
>
>> I fully support a white-list of RDS/QIS with global acceptance and
>> collective scrutiny but even these lists need to be re-evaluated
>> periodically as required by our standards. Perhaps a "global black-list"
>> might be setup for certain cases of misbehavior like the one described
>> above. However, this white-list should not be the only one allowed to be
>> used and national jurisdiction databases (company registries) should also
>> be allowed provided they are adequately evaluated by the CA according to
>> our standards.
>>
> As anyone with any security background can tell you, whitelists address the
> objectives where blacklists address the appearances.

Sure, but perhaps both are needed. Look at Mozilla banning E&Y Hong
Kong. We might encounter some reliable sources that misbehave too.

>
> If you believe that there are national jurisdictional databases, they can
> be added to the whitelist. Indeed, the entire point would be to ensure
> that, for the appropriate jurisdictional boundary, there's a clear
> indication as to appropriate data sources. Then, there is no need for CA
> discretion - or indiscretion.

You are basically suggesting that the evaluation of a data source
performed by the CA (at least for the smaller jurisdictions) be made
public and added in the white-list. I'm fine with that. However, we will
face the same problem if during re-evaluation we discover that some
piece of information is not as reliable as we thought.

>
>> I also support the idea of describing which information is evaluated as
>> "reliable" from a particular source and not completely dismiss a source if
>> they describe in their practices that they accept "some other"
>> irrelevant-to-the-ca information as self-reported.
>>
> So you would also see the whitelist broken down by jurisdiction and by data
> source. Unless and until there is a whitelist, there is no safe way to
> permit that usage you're describing.
>
>
>> It is a very challenging goal, especially because there are so many
>> different jurisdictions from which to collect reliable information. As a
>> more realistic goal, perhaps we could describe the ideal data source
>> evaluation and periodic re-evaluation process more explicitly in the
>> Guidelines, with clear and auditable criteria.
>>
> We're not short of describing expectations. We're short of CAs meeting
> expectations. And as I said, for an adversarial model, it does not matter
> what the best or 'most' do, it only matters what a single one permits. As
> such, a solution to "double down" on language that allows a CA to
> interpretive dance their way out of the objectives is not valuable, nor is
> any solution that relies on auditor review. Indeed, the main argument for
> 'auditable' criteria would be so that CAs could disguise their shady
> practices through a lack of transparent reporting, rather than the
> objective of this thread, which is to improve it through transparency.

My suggestion was that between now and "white-lists with full
transparency that all CAs MUST use", there might be some intermediate
steps to improve the current processes.


Dimitris.

[Tim Hollebeek]

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 <ry...@sleevi.com>
Sent: Friday, September 28, 2018 6:35 PM
To: Tim Hollebeek <tim.ho...@digicert.com>
Cc: Dimitris Zacharopoulos <ji...@it.auth.gr>; Ian Carroll <i...@certly.io>; mozilla-dev-security-policy <mozilla-dev-s...@lists.mozilla.org>; ry...@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 <tim.ho...@digicert.com <mailto:tim.ho...@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 <dev-security-...@lists.mozilla.org <mailto:dev-security-...@lists.mozilla.org> >
On
> Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Friday, September 28, 2018 10:04 AM
> To: Dimitris Zacharopoulos <ji...@it.auth.gr <mailto:ji...@it.auth.gr> >
> Cc: mozilla-dev-security-policy
<mozilla-dev-s...@lists.mozilla.org <mailto:mozilla-dev-s...@lists.mozilla.org> >;
> Ian Carroll <i...@certly.io <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

> <dev-secur...@lists.mozilla.org <mailto:dev-secur...@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 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:
> >
>

> This is because the goal of a given root program is to ensure a
consistently
> operated PKI with a consistent degree of assurance. That CA A accepts Foo
as a
> QIIS and CA B does not, because they both participate in the same PKI
> (namely, the browser's root program), the levels of assurance are not
equal to
> the expectations of the policy. One model of approaching this is to try to
> outsource that lack of assurance to the relying party - for example,
telling
> them that "CA A shouldn't be relied upon" or "CA B is more trustworthy" -
but
> for the Web, that's a fundamentally failed model full of user-hostility.
The
> other approach is to establish more consistent criteria to assess CA A and
CA B
> against, to reduce the divergence in assurance - which is where a
whitelist
> comes from.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org <mailto:dev-secur...@lists.mozilla.org>

[Ryan Sleevi]

On Mon, Oct 1, 2018 at 9:21 AM Dimitris Zacharopoulos <ji...@it.auth.gr>
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 that the QIIS allows it to be self-reported in the
future?

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.
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.

> 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.
>
>
> Again, I might have described my thoughts unclearly. I was only trying to
> say that Subscribers now pay more attention to the CA they chose than they
> did before. They may not choose a "loose" or "weak" CA that easily because
> of the risks associated with that decision.
>

And that has zero relevance to the discussion, or to mitigating the
weakness. The subscriber choice is irrelevant - the attacker's choice is
what matters - and that's why we have things like the Baseline Requirements
to begin with. If we believed that anything above was an appropriate
mitigation for misissuance, we wouldn't need BRs to begin with, we'd just
let the market of reputation sort it out, with bad CAs eventually getting
no customers.

This, of course, also entirely ignores that the "loose" or "weak" CA is
generally more appealing on other grounds (cost, complexity, time to
validate) compared to CAs doing the "right" thing, so we can't even argue
rational self-interest on behalf of Subscribers as somehow being a
mitigation.

> Funny enough, that subjectivity you just described is not permitted of CAs,
> and for good reason. Every one of those certificates needs to be revoked,
> per 4.9.1.1 of the BRs. The CA has also material misstated its warranty for
> these certificates, per 9.6.1.
>
>
> Yet we've seen this being exercised before and definitely in violation of
> the 24 hour window. The main issue that we have seen some CAs struggle with
> and explain in Incident Reports is that this information might actually be
> proven to be accurate and can be re-validated without causing interruptions
> for Subscribers and Relying Parties.
>

This is the stopped-clock argument - that the process to getting that
information doesn't matter, as long as the information turns out eventually
consistent. However, the act of certification is about ensuring that the
process is well-formed. If the only backstop against misissuance is
eventual consistency, then there's no incentive to get the process correct.
And if the process isn't correct, there's nothing to mitigate adversarial
impact.

By comparison, we don't leave the root password to our servers as "secret",
with the assumption that 99/100, the person logging in to that server will
be authorized. Just because it's eventually consistent doesn't mean it's
not fundamentally flawed.

> If you believe that there are national jurisdictional databases, they can
> be added to the whitelist. Indeed, the entire point would be to ensure
> that, for the appropriate jurisdictional boundary, there's a clear
> indication as to appropriate data sources. Then, there is no need for CA
> discretion - or indiscretion.
>
>
> You are basically suggesting that the evaluation of a data source
> performed by the CA (at least for the smaller jurisdictions) be made public
> and added in the white-list. I'm fine with that. However, we will face the
> same problem if during re-evaluation we discover that some piece of
> information is not as reliable as we thought.
>

Of course, but then we end up with a consistent interpretation and
application of that data.

[Dimitris Zacharopoulos]

On 1/10/2018 8:15 μμ, Ryan Sleevi via dev-security-policy wrote:
> On Mon, Oct 1, 2018 at 9:21 AM Dimitris Zacharopoulos <ji...@it.auth.gr>
> 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 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 source's practices) it is self-reported.


>
>
>
> [...]

>
>> Funny enough, that subjectivity you just described is not permitted of CAs,
>> and for good reason. Every one of those certificates needs to be revoked,
>> per 4.9.1.1 of the BRs. The CA has also material misstated its warranty for
>> these certificates, per 9.6.1.
>>
>>
>> Yet we've seen this being exercised before and definitely in violation of
>> the 24 hour window. The main issue that we have seen some CAs struggle with
>> and explain in Incident Reports is that this information might actually be
>> proven to be accurate and can be re-validated without causing interruptions
>> for Subscribers and Relying Parties.
>>
> This is the stopped-clock argument - that the process to getting that
> information doesn't matter, as long as the information turns out eventually
> consistent. However, the act of certification is about ensuring that the
> process is well-formed.

It was considered well-formed when the certificate was issued.

> If the only backstop against misissuance is
> eventual consistency, then there's no incentive to get the process correct.
> And if the process isn't correct, there's nothing to mitigate adversarial
> impact.

This is not what is described in the current requirements. Re-evaluation
of data sources, quarterly internal reviews are some of the existing
controls to check for possible inconsistencies and flaws in existing
processes with a goal of improving and correcting these processes. The
CA audit schemes themselves aim for continuous improvements in all areas
(organizational and technical controls).

I have already agreed that creating a global list of reliable
information sources is great because transparency will bring common
understanding in the evaluation processes. Until we get there though,
there is room for improving existing requirements and, as Tim said, one
does not prevent the other.

>
> By comparison, we don't leave the root password to our servers as "secret",
> with the assumption that 99/100, the person logging in to that server will
> be authorized. Just because it's eventually consistent doesn't mean it's
> not fundamentally flawed.
>

Your example is analogous only if the CA "knowingly" allowed and used
self-reported information from a data source. Just like the
administrators intentionally leaves the root password as "secret" when
they know this is a very insecure practice. My examples described that
the CA WOULD NOT accept and use unreliable information from a data
source but only reliable information that had been previously evaluated.

A better analogy might be for the administrator to set the password to
minimum 8 characters (alphanumeric/mixed case/special characters) and
during re-evaluation decided to improve it to minimum 12 characters.
This change of password policy doesn't imply that the previous setting
was insecure or that the server is compromised.

Similarly, if the CA accepted a piece of information (street address)
from data "source A" that was considered reliable during certificate
issuance, but during re-evaluation the CA discovered that this
information is more reliable in "source B", they can check all existing
validations that include the "street address" attribute and compare it
with the new -more reliable- information. Again, these are theoretical
examples and reality is more complicated. We have seen different
reactions from different CAs in the past for clear cases of mis-issuance
and cases where there is a suspicion that some of the information is not
accurate. The only very clear case which resulted in revocations from
all affected CAs was the .tg TLD compromise
(https://ccadb-public.secure.force.com/mozillacommunications/CACommResponsesOnlyReport?CommunicationId=a051J00003mogw7&QuestionId=Q00052,Q00053).
This seems to be the safest approach in general.


Dimitris.

>> If you believe that there are national jurisdictional databases, they can
>> be added to the whitelist. Indeed, the entire point would be to ensure
>> that, for the appropriate jurisdictional boundary, there's a clear
>> indication as to appropriate data sources. Then, there is no need for CA
>> discretion - or indiscretion.
>>
>>
>> You are basically suggesting that the evaluation of a data source
>> performed by the CA (at least for the smaller jurisdictions) be made public
>> and added in the white-list. I'm fine with that. However, we will face the
>> same problem if during re-evaluation we discover that some piece of
>> information is not as reliable as we thought.
>>
> Of course, but then we end up with a consistent interpretation and
> application of that data.

> _______________________________________________
> dev-security-policy mailing list
> dev-secur...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-security-policy

[Ryan Sleevi]

On Tue, Oct 2, 2018 at 10:02 AM Dimitris Zacharopoulos <ji...@it.auth.gr>
wrote:

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 source's practices) it is self-reported.
>

You're resting a lot of assumptions on a world that doesn't exist, so
perhaps that's where we're at a disconnect. I'm discussing the world that
we have, and the sources CAs are using today as RDS and QIIS. Perhaps it's
not as applicable to ETSI audited CAs, because they share such a tight
government regulatory framework that they primarily only concern themselves
with EU business registries. However, for EV - not QWACs - and particularly
when looking at an international representation and not just a
trans-national representation in the EU, such systems are not the ones
being practiced.

> > This is the stopped-clock argument - that the process to getting that
> > information doesn't matter, as long as the information turns out
> eventually
> > consistent. However, the act of certification is about ensuring that the
> > process is well-formed.
>
> It was considered well-formed when the certificate was issued.
>

Thanks. This confirms the view that I find deeply incompatible with the Web
PKI and improving the CA ecosystem - that it doesn't matter how you got the
answer, as long as the answer looks right in the end. Cheating is not an
acceptable means to getting the right answer, and using unreliable methods
to assert confidence that the data was accurate at time of issue is both
cheating and lying. The assertion by the CA cannot be reasonably stated
through the use of an unreliable data source, full stop.

>
> > If the only backstop against misissuance is
> > eventual consistency, then there's no incentive to get the process
> correct.
> > And if the process isn't correct, there's nothing to mitigate adversarial
> > impact.
>
> This is not what is described in the current requirements. Re-evaluation
> of data sources, quarterly internal reviews are some of the existing
> controls to check for possible inconsistencies and flaws in existing
> processes with a goal of improving and correcting these processes. The
> CA audit schemes themselves aim for continuous improvements in all areas
> (organizational and technical controls).
>

This is not what is described in the current requirements, nor as
practiced. Yes, there is a regular re-evaluation of the CA's controls. No,
it does not require what you describe. And no, it does not excuse using
unreliable data sources in order to wait and see "what's the worst that can
happen," as somehow some perverse risk balancing ("the cost of doing it
right is so expensive, and it's not likely that someone would lie to this
unreliable source, so we'll use this unreliable source" *is* risk
management).

This presumption that audits somehow balance or catch this, however, is
laughable at best. The audits are not only not designed to address this,
they're fundamentally incapable of it, as I mentioned earlier in this
thread. The entire balancing act rests on the auditor knowing that, say,
D&B allows self-reporting of these fields - it doesn't resolve the problem,
it just moves it one step away, to an even less-qualified party because the
auditors are not going to be effective at monitoring everything going on,
because it's not aligned with their business duties.

> I have already agreed that creating a global list of reliable
> information sources is great because transparency will bring common
> understanding in the evaluation processes. Until we get there though,
> there is room for improving existing requirements and, as Tim said, one
> does not prevent the other.
>

I disagree with both you and Tim here - I think this approach to
'incremental' improvement is merely a means to delay meaningful
improvement, even if that improvement is 'tough'. I can understand why, as
CAs, there's value in appearing to do more than nothing, but in an
adversarial model, until the problem is fixed, it's not substantially
better than doing nothing. These approaches to 'incremental' improvements -
such as relying on auditors, expecting QIIS/RDS to have comprehensive
audits and policies around data handling, around quarterly CA reviews -
don't actually address the core problems in any substantive way. However,
they take energy - from CAs and the community - and in that regard, they
prevent discussions about how to 'solve' the problem due to ratholes on how
to 'bootstrap solutions' like transparency ledgers or normative audit
criteria.

>
> >
> > By comparison, we don't leave the root password to our servers as
> "secret",
> > with the assumption that 99/100, the person logging in to that server
> will
> > be authorized. Just because it's eventually consistent doesn't mean it's
> > not fundamentally flawed.
> >
> Your example is analogous only if the CA "knowingly" allowed and used
> self-reported information from a data source. Just like the
> administrators intentionally leaves the root password as "secret" when
> they know this is a very insecure practice. My examples described that
> the CA WOULD NOT accept and use unreliable information from a data
> source but only reliable information that had been previously evaluated.
>

No, it's not analogous. Your hypothetical CA, which does not exist, would
rely on reports, which do not exist, to make decisions, which are not
audited, about this source. My situation was describing an entity who was
'doing their best' and 'making an informed decision'.

Your hypothetical is demonstrably false due to the heavy reliance on D&B by
modern CAs. If your hypothetical world existed, this would have been a
known issue and long resolved. It's not, because it doesn't exist as you
imagine.

[Dimitris Zacharopoulos]

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 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)

I have already stated that I fully agree with this goal :)

The EU regulatory framework does not mandate which registries to use. I
assume that all CAs use the same rules for evaluating information
sources. CAs can use any number of business registries. If a business in
Greece wants to get an EV Certificate from a CA in the US, that CA might
use the Greek Business Registry after properly evaluating it according
to their evaluation procedures.

>
>>> This is the stopped-clock argument - that the process to getting that
>>> information doesn't matter, as long as the information turns out
>> eventually
>>> consistent. However, the act of certification is about ensuring that the
>>> process is well-formed.
>> It was considered well-formed when the certificate was issued.
>>
> Thanks. This confirms the view that I find deeply incompatible with the Web
> PKI and improving the CA ecosystem - that it doesn't matter how you got the
> answer, as long as the answer looks right in the end. Cheating is not an
> acceptable means to getting the right answer, and using unreliable methods
> to assert confidence that the data was accurate at time of issue is both
> cheating and lying. The assertion by the CA cannot be reasonably stated
> through the use of an unreliable data source, full stop.

These are very strong words for something that is clearly not
deliberate. According to the example, the process was well-formed,
evaluations were conducted with the known-at-the-time facts and nothing
was done in bad faith or with intent (until proven otherwise of course).

I have come across some very competent auditors who capture these risks
and gaps in CA operations and insist on seeing them properly
addressed/mitigated, even though they may not be strictly mandated in
the BRs. Most competent auditors I've met care more about Relying
Parties than the actual CA because they understand what's at stake. I am
sure both WT and ETSI have excellent guidance on how to establish a
secure organizational, operational and technical environment and some
auditors use these standards to ensure that CAs adhere to the highest
security expectations. I think your last overly general statement is
unfair to these very competent auditors who have the skills, competence
and deep knowledge to evaluate these complicated standards, propose very
meaningful improvements to CAs, and actually take their obligation for
impartiality, objectivity very seriously.

>
>> I have already agreed that creating a global list of reliable
>> information sources is great because transparency will bring common
>> understanding in the evaluation processes. Until we get there though,
>> there is room for improving existing requirements and, as Tim said, one
>> does not prevent the other.
>>
> I disagree with both you and Tim here - I think this approach to
> 'incremental' improvement is merely a means to delay meaningful
> improvement, even if that improvement is 'tough'. I can understand why, as
> CAs, there's value in appearing to do more than nothing, but in an
> adversarial model, until the problem is fixed, it's not substantially
> better than doing nothing. These approaches to 'incremental' improvements -
> such as relying on auditors, expecting QIIS/RDS to have comprehensive
> audits and policies around data handling, around quarterly CA reviews -
> don't actually address the core problems in any substantive way. However,
> they take energy - from CAs and the community - and in that regard, they
> prevent discussions about how to 'solve' the problem due to ratholes on how
> to 'bootstrap solutions' like transparency ledgers or normative audit
> criteria.

There may be people with enough energy for both but I understand your
argument. I'm happy to contribute in any direction.

Dimitris.

[Ian Carroll]

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 <ji...@it.auth.gr>
> > 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.