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

Thu May 24 08:00:26 MST 2018

Fair enough.  I’m actually more interested with whether the ideas you stated are a good basis for longer term, more substantive changes.  I think they can be.  But we can discuss that at another time.  It’s not really related to Ballot 225.

-Tim

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

I think Chris would have to answer that, as the proposer of the substantive change, and because there are a still a number of unaddressed challenges raised by Peter, that Kirk only partially addressed.

My substantive contribution was to agree with Kirk, that if we're going down this direction, that "language may be so general and vague that CAs won’t have enough guidance on what is permitted and what is not " will indeed be problematic, as we all seem to agree, so rather than rule+exception list (which we know is problematic), if there is a proposal is to change 11.6, then, for all jurisdictions, we should dictate an explicit list in "EVGL 11.6 on a country-by-country basis, ... and with a proposal ... with facts and evidence."

On Thu, May 24, 2018 at 9:29 AM, Tim Hollebeek <tim.hollebeek at digicert.com <mailto:tim.hollebeek at digicert.com> > wrote:

To be clear, I never mentioned any subjective exceptions.  What I hand-waved about is quite concrete, since it’s based on country codes.  Whether that’s implemented as a lookup table or default rules + exception lists is a data structure question that is even farther in the future than the question you didn’t really answer.

I think it is important to pin down at the outset vague things along these lines that people could actually support.  Lookup table by country code(s) is something I could get behind.  It’s basically the same thing, just restated slightly.  So let’s go with that.

Now if the table has country codes on the left, what sorts of things do you envision being useful in the right hand column?

-Tim

From: Ryan Sleevi [mailto:sleevi at google.com <mailto:sleevi at google.com> ] 
Sent: Wednesday, May 23, 2018 5:02 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 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/20180524/995419c7/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/validation/attachments/20180524/995419c7/attachment-0001.p7s>