[Servercert-wg] [EXTERNAL]Re: Clarification about EVG 9.2.4

[Ryan Sleevi]

Hi Kirk,

As always, I appreciate the point to provide clarification. I think it's a
good chance to highlight when you may be confused by something, and seek
clarification first, before responding to a strawman. Regrettably, this
message shares the same.

You suggest it's unrelated points, however, it seems you may simply not
understand. I'm happy to clarify for you to reduce your confusion, since I
can understand you may not be familiar with the developments in the
industry. My suggestion to read the links was to suggest you read
DigiCert's incident report, in depth, as they really showed that even the
strawman arguments being made by Entrust Datacard don't hold water or stand
up to scrutiny. They've shown not only is it possible for a CA to enumerate
the sources their compliance team has identified, but further shown that in
doing so, they've been able to detect industry-wide non-conformities. If
you'll recall, Entrust Datacard was one of the CAs affected, in part
because they'd not been following these discussions and thus not had a
chance to examine their own systems.

I can understand you may not find them persuassive, but I do believe you
may simply be misunderstanding. As always, I remain available to clarify.
Hopefully, the previous message I provided you has shown that what you
believe to be the suggestion - some global list created a priori - is
simply not what's being discussed. As previously captured, if CAs and their
compliance teams, including Entrust Datacard, merely examine their existing
issuance and what organizations they've identified as suitable for
complying with the EV Guidelines, we can quickly and rapidly make progress
on a clear, consistent, and unambiguous list, which resolves a host of
systemic, industry-wide issues (including Entrust DataCard's own issues),
and lead to more reliable certificates for everyone.

Surely you can find that both relevant and persuasive. I see no reason why
we should leave up to each individual CA's discretion on how to arrive at
things. This is no different, in spirit or in execution, then the Forum
long having since recognized "Any other equivalent method" as being
laughably and woefully insecure and inadequate. It's time to move on from
those past, failed approaches, and make real progress!

Again, and to avoid confusion:
Does Entrust Datacard maintain a list of QGIS that it has evaluated as
complying with the EV Guidelines for purposes of incorporation information?
If so, can you please share it?

Of course, it may be the answer is no, and that Entrust Datacard relies on
each validation agent to independently evaluate, for each request, the
appropriate QGIS. The related incident dashboard shows how woefully
inadequate this approach is, so I think we can clearly state that such an
approach is laughably insecure in practice, and thus not worth continuing :)

On Thu, Dec 5, 2019 at 12:51 AM Kirk Hall <Kirk.Hall at entrustdatacard.com>
wrote:

> You always do the same thing: you suggest that someone who disagrees with
> you hasn’t read your messages, and then you criticize them on some
> unrelated point.  Do you really think this advances your case or your
> credibility?
>
>
>
> I did read your postings on the subject “Clarification about EVG 9.2.4”,
> but I did not find them persuasive, or even very relevant.  For further
> details, see this link.
>
>
>
> https://cabforum.org/pipermail/servercert-wg/2019-December/001524.html
>
>
>
> *From:* Ryan Sleevi <sleevi at google.com>
> *Sent:* Wednesday, December 4, 2019 6:38 PM
> *To:* Kirk Hall <Kirk.Hall at entrustdatacard.com>
> *Cc:* Tim Hollebeek <tim.hollebeek at digicert.com>; CA/B Forum Server
> Certificate WG Public Discussion List <servercert-wg at cabforum.org>
> *Subject:* [EXTERNAL]Re: [Servercert-wg] Clarification about EVG 9.2.4
>
>
>
> 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/20191205/3a5a318e/attachment-0001.html>