[cabf_validation] [EXTERNAL]Re: Proposed draft Ballot 225 to strengthen EVGL 11.6 - Operational Existence

Wed May 23 16:46:34 MST 2018

Companies and government bodies will probably require CAs to comply with financial regulations and be registered on a financial regulator register such as FCA before they will release financial documentation.

________________________________
From: Validation <validation-bounces at cabforum.org> on behalf of Ryan Sleevi via Validation <validation at cabforum.org>
Sent: Wednesday, May 23, 2018 10:02:11 PM
To: Tim Hollebeek
Cc: CA/Browser Forum Validation WG List
Subject: Re: [cabf_validation] [EXTERNAL]Re: Proposed draft Ballot 225 to strengthen EVGL 11.6 - Operational Existence

I think that's putting the cart before the horse.

We're certainly interested in making sure good work emerges - i.e. work that it's not necessary to vote against - and so I'm trying to make sure we've got a common understanding of the issues and how they are proposed to be mitigated.

It seems that, as far as standards go, an ideal state is something that is globally applicable, but absent that, we get more consistent results by providing a lookup table rather than an exception list. We've already seen several interpretation issues with and/or clauses in the BRs, and exception lists that rely on subjective interpretation are the bane of consistency.

So, if the proposal is that there is not something globally suitable that doesn't devolve into subjective interpretation - which seems reasonable on its face - I'm trying to understand what the issues with a lookup-table are. In the most uncharitable read, it seems to be to favor 'some' jurisdictions (by letting them implicitly assume the general rule) while discouraging others (forcing them into an exception list) - and I'm not sure the benefit there.

On Wed, May 23, 2018 at 4:57 PM, Tim Hollebeek <tim.hollebeek at digicert.com<mailto:tim.hollebeek at digicert.com>> wrote:

Well, no.  I didn’t say the pinky swear part.

If there’s no validation methods appropriate for the level of verification and the jurisdiction, then you can’t do pinky swears.  You just can’t have that level of rigor in that jurisdiction.  The end user might choose to get a pinky swear certificate instead, but that’s like getting a DV certificate.

But this is all just academic unless you’re seriously considering potentially supporting improvements to identity verification within certificates and the importance of that information if properly vetted (ignoring browser issues and UI, which are browser issues).

Are you?

-Tim

From: Ryan Sleevi [mailto:sleevi at google.com<mailto:sleevi at google.com>]
Sent: Wednesday, May 23, 2018 4:12 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com<mailto:tim.hollebeek at digicert.com>>
Cc: CA/Browser Forum Validation WG List <validation at cabforum.org<mailto:validation at cabforum.org>>

Subject: Re: [cabf_validation] [EXTERNAL]Re: Proposed draft Ballot 225 to strengthen EVGL 11.6 - Operational Existence

I'm not sure that it certainly wouldn't make sense, and that's why I'm trying to unpack.

The implicit statement of this ballot is that the existing methods of verifying existence are insufficient. It then poses to change that, with something that doesn't work across jurisdictional boundaries - as rightfully pointed out. This means that there's going to be some degree of interpretation, by CAs, as to whether or not a given jurisdiction meets those requirements. Doesn't it make sense to normalize that interpretation?

That is, if we're rejecting a globally applicable situation, on the basis of jurisdictional grounds, and expect to have per-jurisdiction exceptions, then for the benefit of consistency, we should express these as per-jurisdiction rules, rather than as general rules (subject to interpretation) and exceptions.

I think the outcome is similar to what you pose: which is "Here's a method for validating operational existence using financial information", and then listing all the jurisdictions and countries that such a method is applicable to. Then you also list "Here's a method for validating operational existence using a pinky-swear", and then listing all the jurisdictions and countries in which pinky-swears are legally binding and appropriate.

What doesn't seem to make sense is "Here's the method for validating operational existence", which then only describes financial information (or pinky-swears), and then says "And if you can't do this, but you're in X, Y, and Z, you can use pinky swears instead".

On Wed, May 23, 2018 at 3:01 PM, Tim Hollebeek <tim.hollebeek at digicert.com<mailto:tim.hollebeek at digicert.com>> wrote:

Well, it certainly wouldn’t make sense to explicitly list the countries where EV issuance is permitted.  We should layer improvements atop the existing rules, to avoid undue impact on existing EV certificates in existing browsers.  Browsers can do what they want with information like “this certificate is an EV certificate, with the following validation enhancements that are appropriate for an allowed for the corresponding country code.”  Though to keep complexity down, it’s probably better to have a simpler model where we have something like “here are the 2019 identity validation goals for a defined security level, and here’s the 2019 validation rules for the US for that level.”

For the specific case of tax rules, we could do the same thing, especially in cases where the tax rules differ enough to have a tangible impact on the quality of the validation, but financial stuff tends to be an area where the world is a bit more homogeneous, for obvious practical reasons.

Likewise, for others of these as well, there are certain cases and large portions of the world that are homogeneous enough that a general rules will work.  “Here’s how you validate operational existence using financial information for a country in the eurozone” might make sense as an example.

-Tim

From: Ryan Sleevi [mailto:sleevi at google.com<mailto:sleevi at google.com>]
Sent: Wednesday, May 23, 2018 12:52 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com<mailto:tim.hollebeek at digicert.com>>; CA/Browser Forum Validation WG List <validation at cabforum.org<mailto:validation at cabforum.org>>
Subject: Re: [cabf_validation] [EXTERNAL]Re: Proposed draft Ballot 225 to strengthen EVGL 11.6 - Operational Existence

Should that same logic apply for those with such tax authorities?

That is, wouldn't it make sense to explicitly list the countries where EV issuance is permitted, according to these rules? That would certainly make it far easier to note which countries are permitted to obtain EV certificates, and what methods for each country are acceptable for that validation, on a country-by-country basis. This uniformity in approach would make it easier to avoid misinterpretation about whether or not a given jurisdiction meets the requirements posed.

On Wed, May 23, 2018 at 12:35 PM, Tim Hollebeek via Validation <validation at cabforum.org<mailto:validation at cabforum.org>> wrote:

I’ve supported this for a long time. As much as I hate country-by-country rules, I don’t think jurisdiction-neutral validation requirements can always be written for requirements like this.  The world’s legal systems are just too diverse.  I think even with very good rules, country-specific exceptions are inevitable.

We had similar issues with questions of simple geography, which don’t have uniform global understandings.

-Tim

I’d suggest this:  Let CAs who operate in other countries propose future amendments to EVGL 11.6 on a country-by-country basis, with reasons (e.g., “we can’t do those checks here because…”) and with a proposal for an alternative method for verifying an Applicant’s “operational existence” in that country, with facts and evidence.  The Forum can then review adopt those proposals on a country-by-country basis – limited to Applicants in those countries only – and add them in an Appendix to the EVGL.  This can grow over time as needed.

_______________________________________________
Validation mailing list
Validation at cabforum.org<mailto:Validation at cabforum.org>
https://cabforum.org/mailman/listinfo/validation

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180523/9aa2b829/attachment-0001.html>