Re: Concerns with Dun & Bradstreet as a QIIS

[Ryan Sleevi via dev-security-policy]

Yes, we can punt the problem down a few years, by allowing CAs to
self-report in unauditable ways, and shift the burden of evaluation on to
the community to try and detect CAs misbehaving.

Or we can take sensible steps forward that nip the problem at its root,
don’t require misunderstanding or misusing unrelated technologies, and
instead achieve the goals that CAs have been claiming are valuable to
achieve years sooner.

Obviously, simpler is better - and a whitelist of QGIS quickly establishes
an interoperable and consistent baseline for organizational information,
and can be readily deployed today, without any unnecessary infrastructure,
and with immediate utility to existing relying parties.

On Fri, Sep 28, 2018 at 7:43 PM Tim Hollebeek 
wrote:

> Perhaps a simple first step is to mandate disclosure of which information
> source was used for validation.  Then if someone uses Google Maps or
> similar, People Who Pay Attention To Such Things can start a public
> discussion about whether the source is a QIIS, and whether the certificate
> is mis-issued.
>
> This would be yet another use case for my certificate metadata transparency
> idea.  CAs have lots of information about the validation, issuance,
> management, and revocation of certificates that really does not need to be
> private.  As I've noted a few times this year, the issue keeps coming up.
>
> If there were more hours in my day, there'd be an RFC for it already.  If
> anyone wants to help with it, I'd be more than happy to work with them.
>
> -Tim
>
> > -Original Message-
> > From: dev-security-policy  >
> On
> > Behalf Of Ryan Sleevi via dev-security-policy
> > Sent: Friday, September 28, 2018 10:04 AM
> > To: Dimitris Zacharopoulos 
> > Cc: mozilla-dev-security-policy
> ;
> > Ian Carroll 
> > Subject: Re: Concerns with Dun & Bradstreet as a QIIS
> >
> > On Fri, Sep 28, 2018 at 1:22 AM Dimitris Zacharopoulos via
> dev-security-policy
> >  wrote:
> >
> > >
> > > Forgive my ignorance, but could you please explain what was your
> > > ultimate goal, as "an attacker", what were you hoping to gain and how
> > > could you use this against Relying Parties?
> > >
> > > I read your email several times but I could not easily find a case
> > > where your fake address creates any serious concern for Relying
> > > Parties. Even if you used the same street address as CloudFlare, the
> > > CA would check against the database and would find two company records
> > > that share the same address. That would obviously block the process
> > > and additional checks would take place. Now, as a way to delay
> > > certificate issuance for CloudFlare, I find it interesting but it
> > > certainly doesn't seem to affect Relying Parties.
> > >
> >
> > I'm not Ian, but I would have thought his email would have been obvious
> and
> > clear. The confusion here is that two jurisdictions can allow different
> entities
> > the same name. The EVGs seek to resolve this by making use of a variety
> of
> > ancilliary fields - such as serialNumber and the incorporation
> information
> - to
> > presumably attempt to establish to the relying party the identity they're
> > speaking to.
> >
> > In the "Stripe, Inc" case, the user was able to distinguish 'real' from
> 'fake' by
> > virtue of the incorporation information - Kentucky vs California.
> > However, in this case, the attack went further, in as much as through the
> CA
> > using an unreliable datasource to verify the jurisdictional information.
> > If the CA used an unreliable datasource, then the end user would see
> > something that, for intents and purposes, appears the same.
> >
> > I'm not sure your point about the same address - Ian made it clear it was
> a
> > different but *similar* address - and I'm not sure why you suggest it
> would
> > block for the legitimate subscriber. Does that explain it simply enough?
> >
> >
> > > And to take this one step further, I believe there are several GISs
> > > that also accept whatever address you tell them because:
> > >
> > >  1. They have no reason to believe that you will lie to them (they know
> > > who you are and in some Jurisdictions you might be prosecuted for
> > > lying to the government)
> > >  2. No foreseeable harm to others could be done if you misrepresent
> your
> > > own address.
> > >
> >
> > Then they are not Reliable nor QIISes. Full stop.
> >
> >
> > > 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
> > 

RE: Concerns with Dun & Bradstreet as a QIIS

[Tim Hollebeek via dev-security-policy]

Perhaps a simple first step is to mandate disclosure of which information
source was used for validation.  Then if someone uses Google Maps or
similar, People Who Pay Attention To Such Things can start a public
discussion about whether the source is a QIIS, and whether the certificate
is mis-issued.

This would be yet another use case for my certificate metadata transparency
idea.  CAs have lots of information about the validation, issuance,
management, and revocation of certificates that really does not need to be
private.  As I've noted a few times this year, the issue keeps coming up.

If there were more hours in my day, there'd be an RFC for it already.  If
anyone wants to help with it, I'd be more than happy to work with them.

-Tim

> -Original Message-
> From: dev-security-policy 
On
> Behalf Of Ryan Sleevi via dev-security-policy
> Sent: Friday, September 28, 2018 10:04 AM
> To: Dimitris Zacharopoulos 
> Cc: mozilla-dev-security-policy
;
> Ian Carroll 
> Subject: Re: Concerns with Dun & Bradstreet as a QIIS
> 
> On Fri, Sep 28, 2018 at 1:22 AM Dimitris Zacharopoulos via
dev-security-policy
>  wrote:
> 
> >
> > Forgive my ignorance, but could you please explain what was your
> > ultimate goal, as "an attacker", what were you hoping to gain and how
> > could you use this against Relying Parties?
> >
> > I read your email several times but I could not easily find a case
> > where your fake address creates any serious concern for Relying
> > Parties. Even if you used the same street address as CloudFlare, the
> > CA would check against the database and would find two company records
> > that share the same address. That would obviously block the process
> > and additional checks would take place. Now, as a way to delay
> > certificate issuance for CloudFlare, I find it interesting but it
> > certainly doesn't seem to affect Relying Parties.
> >
> 
> I'm not Ian, but I would have thought his email would have been obvious
and
> clear. The confusion here is that two jurisdictions can allow different
entities
> the same name. The EVGs seek to resolve this by making use of a variety of
> ancilliary fields - such as serialNumber and the incorporation information
- to
> presumably attempt to establish to the relying party the identity they're
> speaking to.
> 
> In the "Stripe, Inc" case, the user was able to distinguish 'real' from
'fake' by
> virtue of the incorporation information - Kentucky vs California.
> However, in this case, the attack went further, in as much as through the
CA
> using an unreliable datasource to verify the jurisdictional information.
> If the CA used an unreliable datasource, then the end user would see
> something that, for intents and purposes, appears the same.
> 
> I'm not sure your point about the same address - Ian made it clear it was
a
> different but *similar* address - and I'm not sure why you suggest it
would
> block for the legitimate subscriber. Does that explain it simply enough?
> 
> 
> > And to take this one step further, I believe there are several GISs
> > that also accept whatever address you tell them because:
> >
> >  1. They have no reason to believe that you will lie to them (they know
> > who you are and in some Jurisdictions you might be prosecuted for
> > lying to the government)
> >  2. No foreseeable harm to others could be done if you misrepresent your
> > own address.
> >
> 
> Then they are not Reliable nor QIISes. Full stop.
> 
> 
> > In my understanding, this is the process each CA must perform to
> > evaluate every Data Source before granting them the "Reliable" or
> > "Qualified" status. Self-reported information without any supporting
> > evidence is clearly not acceptable. I have not evaluated this database
> > that you mention but if they accept self-reporting for "Street Address"
> > and don't perform any additional verification (like asking you for a
> > utility bill or cross-referencing it with a government database), then
> > the "Street Address" information is unreliable and the CA's evaluation
> > process should catch that.
> >
> > That doesn't mean that the rest of the information is also unreliable.
> > For example, an Information Source might describe in their
> > documentation practices how they verify each piece of information, for
> example:
> >
> 
> I disagree with this assessment, and I think it's precisely why greater
> restriction is needed on the flexibility of CAs to make such
interpretations. I
> understand the point you're 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
> 

Re: Visa Issues

[Wayne Thayer via dev-security-policy]

On Fri, Sep 28, 2018 at 12:29 PM Eric Mill  wrote:

>
>
> On Thu, Sep 27, 2018 at 5:22 PM Wayne Thayer via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
>> Visa has filed a bug [1] requesting removal of the eCommerce root from the
>> Mozilla root store. Visa has also responded to the information requested
>> in
>> the qualified audits bug [2], but it's unclear if or when they will
>> respond
>> to the issues list presented in this thread. Two weeks have passed since I
>> posted the issues list, and I see no reason to delay the complete distrust
>> of Visa's eCommerce root. That is likely to happen in Firefox 64 [3] via
>> removal of the root from NSS version 3.40 . Visa is still welcome to
>> respond to the issues list, but I think the removal of Visa's only
>> included
>> root, and thus Visa, from the Mozilla CA Certificate Program implies that
>> this discussion has reached a conclusion.
>>
>
> Visa also stated in their removal bug:
>
> "Visa’s plan is to remove the SHA1 root and introduce a new SHA2 and ECC
> root."
>
> Were Visa to apply to the Mozilla program with one or more new roots,
> would those be new discussions, or would that cause this discussion about
> Visa's history of issues to be re-opened?
>
> It would be a new discussion in which I think it is safe to assume that
Visa's prior issues would be considered, as well as their response (if any)
to this discussion.

-- Eric
>
>
>>
>> - Wayne
>>
>> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1493822
>> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1485851#c2
>> [3] https://wiki.mozilla.org/Release_Management/Calendar
>>
>> On Sun, Sep 23, 2018 at 1:15 PM Ryan Sleevi  wrote:
>>
>> >
>> >
>> > On Thu, Sep 13, 2018 at 3:26 PM Wayne Thayer via dev-security-policy <
>> > dev-security-policy@lists.mozilla.org> wrote:
>> >
>> >> Visa recently delivered new qualified audit reports for their eCommerce
>> >> Root that is included in the Mozilla program. I opened a bug [1] and
>> >> requested an incident report from Visa.
>> >>
>> >> Visa was also the subject of a thread [2] earlier this year in which I
>> >> stated that I would look into some of the concerns that were raised.
>> I've
>> >> done that and have compiled the following issues list:
>> >>
>> >> https://wiki.mozilla.org/CA:Visa_Issues
>> >>
>> >> While I have attempted to make this list as complete, accurate, and
>> >> factual
>> >> as possible, it may be updated as more information is received from
>> Visa
>> >> and the community.
>> >>
>> >> I would like to request that a representative from Visa engage in this
>> >> discussion and provide responses to these issues.
>> >>
>> >> - Wayne
>> >>
>> >> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1485851
>> >> [2]
>> >>
>> >>
>> https://groups.google.com/d/msg/mozilla.dev.security.policy/NNV3zvX43vE/ns8UUwp8BgAJ
>> >
>> >
>> > I've not seen Visa engage in this discussion. The silence is rather
>> > deafening, and arguably unacceptably so.
>> >
>> > With respect to the Qualified Audit, Visa's response as to the substance
>> > of the issue is particularly unsettling.
>> > https://bugzilla.mozilla.org/show_bug.cgi?id=1485851#c3 demonstrates
>> that
>> > they've not actually remediated the qualification, that they've further
>> > failed to meet the BRs requirements on revocations by any reasonable
>> > perspective, and they don't even have a plan yet to remedy this issue.
>> >
>> > Examining the bug itself is fairly disturbing, and the responses likely
>> > reveal further BR violations. For example, the inability to obtain
>> evidence
>> > of domain validation information reveals that there are further issues
>> with
>> > 2-7.3 - namely, maintaining those logs for 7 years. The response to
>> 2-7.3
>> > suggests that there are likely more endemic issues around the issuance.
>> >
>> > Given the past issues, the recently identified issues (that appear to
>> have
>> > been longstanding), and the new issues that Visa's PKI Policy team is
>> > actively engaging in, I believe it would be appropriate and necessary to
>> > consider removing trust in this CA.
>> >
>> ___
>> dev-security-policy mailing list
>> dev-security-policy@lists.mozilla.org
>> https://lists.mozilla.org/listinfo/dev-security-policy
>>
>
>
> --
> konklone.com | @konklone 
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Visa Issues

[Eric Mill via dev-security-policy]

On Thu, Sep 27, 2018 at 5:22 PM Wayne Thayer via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Visa has filed a bug [1] requesting removal of the eCommerce root from the
> Mozilla root store. Visa has also responded to the information requested in
> the qualified audits bug [2], but it's unclear if or when they will respond
> to the issues list presented in this thread. Two weeks have passed since I
> posted the issues list, and I see no reason to delay the complete distrust
> of Visa's eCommerce root. That is likely to happen in Firefox 64 [3] via
> removal of the root from NSS version 3.40 . Visa is still welcome to
> respond to the issues list, but I think the removal of Visa's only included
> root, and thus Visa, from the Mozilla CA Certificate Program implies that
> this discussion has reached a conclusion.
>

Visa also stated in their removal bug:

"Visa’s plan is to remove the SHA1 root and introduce a new SHA2 and ECC
root."

Were Visa to apply to the Mozilla program with one or more new roots, would
those be new discussions, or would that cause this discussion about Visa's
history of issues to be re-opened?

-- Eric


>
> - Wayne
>
> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1493822
> [2] https://bugzilla.mozilla.org/show_bug.cgi?id=1485851#c2
> [3] https://wiki.mozilla.org/Release_Management/Calendar
>
> On Sun, Sep 23, 2018 at 1:15 PM Ryan Sleevi  wrote:
>
> >
> >
> > On Thu, Sep 13, 2018 at 3:26 PM Wayne Thayer via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >
> >> Visa recently delivered new qualified audit reports for their eCommerce
> >> Root that is included in the Mozilla program. I opened a bug [1] and
> >> requested an incident report from Visa.
> >>
> >> Visa was also the subject of a thread [2] earlier this year in which I
> >> stated that I would look into some of the concerns that were raised.
> I've
> >> done that and have compiled the following issues list:
> >>
> >> https://wiki.mozilla.org/CA:Visa_Issues
> >>
> >> While I have attempted to make this list as complete, accurate, and
> >> factual
> >> as possible, it may be updated as more information is received from Visa
> >> and the community.
> >>
> >> I would like to request that a representative from Visa engage in this
> >> discussion and provide responses to these issues.
> >>
> >> - Wayne
> >>
> >> [1] https://bugzilla.mozilla.org/show_bug.cgi?id=1485851
> >> [2]
> >>
> >>
> https://groups.google.com/d/msg/mozilla.dev.security.policy/NNV3zvX43vE/ns8UUwp8BgAJ
> >
> >
> > I've not seen Visa engage in this discussion. The silence is rather
> > deafening, and arguably unacceptably so.
> >
> > With respect to the Qualified Audit, Visa's response as to the substance
> > of the issue is particularly unsettling.
> > https://bugzilla.mozilla.org/show_bug.cgi?id=1485851#c3 demonstrates
> that
> > they've not actually remediated the qualification, that they've further
> > failed to meet the BRs requirements on revocations by any reasonable
> > perspective, and they don't even have a plan yet to remedy this issue.
> >
> > Examining the bug itself is fairly disturbing, and the responses likely
> > reveal further BR violations. For example, the inability to obtain
> evidence
> > of domain validation information reveals that there are further issues
> with
> > 2-7.3 - namely, maintaining those logs for 7 years. The response to 2-7.3
> > suggests that there are likely more endemic issues around the issuance.
> >
> > Given the past issues, the recently identified issues (that appear to
> have
> > been longstanding), and the new issues that Visa's PKI Policy team is
> > actively engaging in, I believe it would be appropriate and necessary to
> > consider removing trust in this CA.
> >
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>


-- 
konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: InfoCert investment in LuxTrust

[Wayne Thayer via dev-security-policy]

Yves,

Thank you for bringing this to our attention. Section 8.1 of the Mozilla
Root Store policy [1] applies here. It is not completely clear to me that
50% ownership is a "controlling stake", but even if it is, InfoCert is
already a member of the Mozilla root program by way of its acquisition of
Camerfirma earlier this year. In that case, our policy simply requires the
following:

Mozilla MUST be notified of any resulting changes in the CA's CP or CPS.

Can you confirm that this investment will cause no CP/CPS changes other
than the updates to the overview chapter that you described?

- Wayne

On Fri, Sep 28, 2018 at 8:38 AM Yves Nullens via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Dear all,
>
> We would like to inform you that Tecnoinvestimenti, through its subsidiary
> InfoCert S.p.A. ("InfoCert"), has signed an agreement to invest into
> LuxTrust. The shareholding will be as follows:
>
> -  50% historic shareholders
>
> -  50% Infocert
>
>  This investment has currently no impact/modification
>
> o   on the organization
>
> o   on the services provided
>
> o   on the infrastructure
>
> LSTI our conformity assessment body and ILNAS the Luxemburgish national
> entity in charge of supervising our certification have also just been
> informed of this investment.
>
>
> We plan to add in the overview chapter of our CP, CPS Infocert to the list
> of entities constituting our partnership : "LuxTrust is a partnership
> between the Luxembourg government, the major private financial actors in
> Luxembourg and Infocert"
>
> Best regards,
> Yves Nullens
>
> [LuxTrust_logo_blue_signature]
>
>
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Concerns with Dun & Bradstreet as a QIIS

[Ian Carroll via dev-security-policy]

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 by specifying the company's 
DUNS number. This means that they aren't searching for a given company name; 
any conflicting companies would not come up in a search.

Also, I think you overestimate validation agents; Comodo actually found the 
real Cloudflare on another QIIS and emailed me saying they found a "similar" 
company, but was happy to ignore it when I gave them a valid DUNS number.

> And to take this one step further, I believe there are several GISs that 
> also accept whatever address you tell them because:
> 
>  1. They have no reason to believe that you will lie to them (they know
> who you are and in some Jurisdictions you might be prosecuted for
> lying to the government)
>  2. No foreseeable harm to others could be done if you misrepresent your
> own address.
> 
> Since we are discussing about Data/Information Sources, the BRs define 
> how CAs should evaluate a Data Source and declaring it "Reliable".
> 
> 
> "3.2.2.7 Data Source Accuracy
> 
> Prior to using any data source as a Reliable Data Source, the CA SHALL 
> evaluate the source for its reliability, accuracy, and resistance to 
> alteration or falsification. The CA SHOULD consider the following during 
> its evaluation:
> 
>  1. The age of the information provided,
>  2. The frequency of updates to the information source,
>  3. The data provider and purpose of the data collection,
>  4. The public accessibility of the data availability, and
>  5. The relative difficulty in falsifying or altering the data.
> 
> Databases maintained by the CA, its owner, or its affiliated companies 
> do not qualify as a Reliable Data Source if the primary purpose of the 
> database is to collect information for the purpose of fulfilling the 
> validation requirements under this Section 3.2."
> 
> The EVGs also describe how to evaluate and declare the "Qualified" status:
> 
> 
>   "11.11.5. Qualified Independent Information Source
> 
> A Qualified Independent Information Source (QIIS) is a regularly-updated 
> and publicly available database that is generally recognized as a 
> dependable source for certain information. A database qualifies as a 
> QIIS if the CA determines that:
> 
> (1) Industries other than the certificate industry rely on the database 
> for accurate location, contact, or other information; and
> 
> (2) The database provider updates its data on at least an annual basis.
> 
> The CA SHALL use a documented process to check the accuracy of the 
> database and ensure its data is acceptable, including reviewing the 
> database provider's terms of use. The CA SHALL NOT use any data in a 
> QIIS that the CA knows is (i) self-reported and (ii) not verified by the 
> QIIS as accurate. Databases in which the CA or its owners or affiliated 
> companies maintain a controlling interest, or in which any Registration 
> Authorities or subcontractors to whom the CA has outsourced any portion 
> of the vetting process (or their owners or affiliated companies) 
> maintain any ownership or beneficial interest, do not qualify as a QIIS."
> 
> 
> In my understanding, this is the process each CA must perform to 
> evaluate every Data Source before granting them the "Reliable" or 
> "Qualified" status. Self-reported information without any supporting 
> evidence is clearly not acceptable. I have not evaluated this database 
> that you mention but if they accept self-reporting for "Street Address" 
> and don't perform any additional verification (like asking you for a 
> utility bill or cross-referencing it with a government database), then 
> the "Street Address" information is unreliable and the CA's evaluation 
> process should catch that.
> 
> That doesn't mean that the rest of the information is also unreliable. 
> For example, an Information Source might describe in their documentation 
> practices how they verify each piece of information, for example:
> 
>   * the Jurisdicion of Incorporation (they check official government
> records),
>   * registry number (they check official government 

Re: Concerns with Dun & Bradstreet as a QIIS

[Ryan Sleevi via dev-security-policy]

On Fri, Sep 28, 2018 at 1:22 AM Dimitris Zacharopoulos via
dev-security-policy  wrote:

>
> Forgive my ignorance, but could you please explain what was your
> ultimate goal, as "an attacker", what were you hoping to gain and how
> could you use this against Relying Parties?
>
> I read your email several times but I could not easily find a case where
> your fake address creates any serious concern for Relying Parties. Even
> if you used the same street address as CloudFlare, the CA would check
> against the database and would find two company records that share the
> same address. That would obviously block the process and additional
> checks would take place. Now, as a way to delay certificate issuance for
> CloudFlare, I find it interesting but it certainly doesn't seem to
> affect Relying Parties.
>

I'm not Ian, but I would have thought his email would have been obvious and
clear. The confusion here is that two jurisdictions can allow different
entities the same name. The EVGs seek to resolve this by making use of a
variety of ancilliary fields - such as serialNumber and the incorporation
information - to presumably attempt to establish to the relying party the
identity they're speaking to.

In the "Stripe, Inc" case, the user was able to distinguish 'real' from
'fake' by virtue of the incorporation information - Kentucky vs California.
However, in this case, the attack went further, in as much as through the
CA using an unreliable datasource to verify the jurisdictional information.
If the CA used an unreliable datasource, then the end user would see
something that, for intents and purposes, appears the same.

I'm not sure your point about the same address - Ian made it clear it was a
different but *similar* address - and I'm not sure why you suggest it would
block for the legitimate subscriber. Does that explain it simply enough?


> And to take this one step further, I believe there are several GISs that
> also accept whatever address you tell them because:
>
>  1. They have no reason to believe that you will lie to them (they know
> who you are and in some Jurisdictions you might be prosecuted for
> lying to the government)
>  2. No foreseeable harm to others could be done if you misrepresent your
> own address.
>

Then they are not Reliable nor QIISes. Full stop.


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

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

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

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

This is because the goal of a given root program is to ensure a
consistently operated PKI with a consistent degree of assurance. That CA A
accepts Foo as a QIIS and CA B does not, because they both participate in
the same PKI (namely, the browser's root program), the levels of assurance
are not equal to the expectations of the policy. One model of approaching
this is to try to outsource that lack of assurance to the relying party -
for example, telling them that "CA A shouldn't be relied