[Servercert-wg] Clarification about EVG 9.2.4

[Ryan Sleevi]

On Wed, Dec 4, 2019 at 9:17 PM Kirk Hall <Kirk.Hall at entrustdatacard.com>
wrote:

> It would be a massive project for the Forum to catalogue – and maintain
> through frequent changes including changes of URLs, etc. – 100% of the all
> world’s national, state, and local registries where a business can be
> incorporated or licensed.  Who would spend the time on this?
>

It seems like you may not have read the links? I've seen DigiCert make a
great start at this.

And I don't think anyone has ever suggested, besides yourself, that it
needs to be a perfect list at first. After all, if we simply started from
what CAs use today, such as what Entrust's compliance team uses, I'm sure
we'd see it's quickly able to accommodate existing issuance.


> And if a registry is not included on the Forum’s approved list – would a
> CA be prohibited from using that registry to issue an EV certificate to an
> Applicant even though it is the correct place to obtain the data and even
> though the registry should be on the list?
>

Of course. After all, the purpose of requirements - whether the Baseline
Requirements or the EV Guidelines - is to ensure that, no matter what CA is
involved, we obtain a consistent result.

We obtain that with a list. If an entity is not on the list, it's not
issued, until it's clear that it should be. That's no different than our
existing process for resolving ambiguities.

Luckily, we know if CAs contributed their existing lists of QGISes, this
would easily accommodate existing issuance. So this should be both trivial
for CAs to produce, and easily lead to consistent results, right?


>
>
> The current members of the Forum are probably not even competent to
> assemble such a complete list as I’m not sure our membership issues in
> every country of the world.   I recall from a few years ago that in Japan,
> in some cases a CA must physically visit a local registration office
> nearest to the corporation to obtain a paper record to confirm a
> corporation’s existence – there was no national online registry.  So do we
> have to list all the local office locations?
>

Luckily, that's not the suggestion, so you're arguing against a strawman :)
I'm sure we can discuss these issues as they come up. Does Entrust not
issue EV certificates to Japan?


>
>
> Not sure what problem this proposal is solving.  Seems like it would
> create its own new problem – an approved list that is incomplete and always
> needs updating.
>

Luckily, you just misunderstood the proposal, and that's hopefully easily
corrected.


> This all started when Dimitris asked about the specific (and potentially
> confusing) language of our current EVGL rules about how to encode the
> registry location in an EV cert showing where a Subject was incorporated or
> licensed.  It seems the only open question is, when the business was
> incorporated or licensed in a Locality office, should we automatically
> include the State/Province/Canton location (if any) as well as the Country
> location.  My opinion is yes, and I can’t see it would do any harm – these
> are pretty rare cases so probably not worth spending too many cycles on
> this.  I can’t recall any reported instance where there has been a problem
> related to encoding the place of incorporation or licensing of an EV cert
> when the place was a locality.
>

While I recently learned that Entrust Datacard has not been following
compliance bugs, and thus likely unfamiliar with the state of EV in the
industry, https://wiki.mozilla.org/CA/Incident_Dashboard shows that,
systemically, EV is deeply flawed in practice, particularly around the
jurisdiction information. DigiCert has really been leading in the efforts
for industry-wide cleanups, especially with their notifications and problem
reports to a number of CAs that stemmed from their own challenges, and
really harkens back to the days of CAs and browsers working together to
strengthen things.

My hope is that Entrust Datacard would be able to apply that same energy
and zeal, using its own reviewed sources of QGISes from its years of
operational experience, so that we can make sure that we're solving the
systemic, industry-wide issues. It's important that we make sure to address
problems at their root, systemic causes, and not just paper over them.
That's why the incident reporting process is so useful and valuable, and
why it's important to make sure that we learn from patterns of issues and
seek to meaningfully solve them.

I realize that for a CA only looking at how they do things, this may seem
overkill. Of course, browsers and relying parties - those who the
certificates are meant to serve and be useful for - care much more about
lasting and meaningful changes, that are robust at their core and not
variable from CA to CA. After all, isn't the fundamental goal of our work
here, whether in TLS, S/MIME, or code-signing, that regardless of the CA
that issued it, every certificate should provide exactly the same level of
assurance as an equivalent certificate issued by another CA? Whether we
view that through the lens of DV, OV, or EV, I'm sure we can agree that
consistency between every CA is why we work on standards. The way we get
consistency is through clear, understandable, unambiguous rules, that are
fair and equitable for all CAs.

We should definitely take inspiration from GLEIF, who recognized the
fundamental quality issues if you do anything less than that.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191204/db9fbadd/attachment.html>