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

Ryan Sleevi sleevi at google.com
Wed Dec 4 15:32:18 MST 2019 

While certainly not opposed to a dialog, I would not agree with how you
phrased it.

It's important that we use the right tool for the job, and it's perfectly
OK for there to be different approaches for different problems. We don't
need all problems to be solved by one solution. Generally speaking, the
"standard" that tries to do everything for everyone often does the wrong
thing for anyone.

I have tremendous respect for GLEIF and what LEIs are trying to address,
and think they're an incredibly valuable tool for a set of problems. But I
do think the problem(s) that EV certificates set out to solve are not
necessarily the same, and that there's real risk in trying to provide a
unified or harmonized approach.

In many ways, this can be thought of similar to the discussions around
QWACs and TLS certificates, which at their core, seek to address different
problems and provide different guarantees. As many European CAs can tell
you, and especially both the browsers and the EU Commission, trying to have
one certificate fit both means significantly more challenges, and
significantly more overhead, without necessarily a commiserate return. Or,
I suppose we could say the same thing when discussing LEIs in TLS.

Again, that's not to suggest opposition to dialog, because I think there is
certainly a lot of industry expertise from GLEIF for the set of problems
GLEIF has set out to solve, and we can and should benefit from that if
possible. However, it's a reminder to be cognizant that it's OK to be
different and have different needs, and to recognize the challenges in
premature standardization or in attempting to get round pegs and square
holes to play nicely, just because they're pegs and holes :)

On Wed, Dec 4, 2019 at 5:26 PM Stephan Wolf <Stephan.Wolf at gleif.org> wrote:

> Thanks. Maybe we could agree on a joint approach. Might be more difficult
> and requires dialog, but it would help almost all industries.
>
> Wouldn’t you agree that „competing standards“ are a contradiction in
> itself? It is more a sign of „not invented here“ and/or trying to find a
> fast track. Not always helpful.
>
>
> ———
> Sent from my mobile device
>
>
> On Dec 4, 2019, at 23:21, Ryan Sleevi <sleevi at google.com> wrote:
>
> 
> Thanks for the offer, Stephan.
>
> As mentioned on the calls, I'm quite familiar with the approach GLEIF
> used, and extensively studied the associated documentation. In fact, it's
> been referenced to a number of CAs who have misissued certificates -
> including the CA who misissued gleif.org's certificate. So it's
> definitely a sound approach used, and one that leads to a much more
> predictable result.
>
> The LEI RA list is a great starting point, although with some caveats in
> that it contains a set of organizations that aren't necessarily the same as
> what we look for in EV certificates, which is understandable given the
> differences in LEI and EV. However, the approach is sound, and as a
> starting point, it's a great starting point.
>
> DigiCert has been a leader in modeling some of this through incident
> responses like https://bugzilla.mozilla.org/show_bug.cgi?id=1576013 ,
> which hopefully more CAs are familiar with and looking at for inspiration,
> especially given that, industry wide, EV jurisdiction information has seen
> significant and seriously disappointing quality issues.
>
> This is definitely an area where CAs can and should be leading and driving
> the discussion though. As the presumptive experts in this space, and with
> long-standing internal policies that accumulate this information (in terms
> of what QGIS sources are valid), it should be relatively trivial to compile
> an initial list similar to LEIs, and from there, discuss any controversial
> or complicated issues. This would holistically solve a swath of systemic
> issues.
>
> On Wed, Dec 4, 2019 at 5:13 PM Stephan Wolf <Stephan.Wolf at gleif.org>
> wrote:
>
>> Happy to volunteer with this approach. In the LEI system, we give clear
>> guidance to the LEI issuers in which jurisdiction they should use ISO
>> 3166-1 (e.g. Germany) and ISO 3166-2 (e.g. in the US). The discriminating
>> element is the use of common company law in a country. We also publish a
>> list of public registries which shall be used for validation and
>> verification. Both together provide a pretty good view.
>>
>> Please let me know if you wish to know more.
>>
>> ———
>> Sent from my mobile device
>>
>>
>> On Dec 4, 2019, at 22:50, Ryan Sleevi via Servercert-wg <
>> servercert-wg at cabforum.org> wrote:
>>
>> 
>> https://cabforum.org/pipermail/servercert-wg/2019-December/001509.html
>>
>>  Of course, a more meaningful way to solve it, which we've discussed for
>> 3+
>> years with limited progress, it seems, although repeated expressions of
>> interest, would be to take the approach that LEI did which is to enumerate
>> the appropriate (Business) Registration Authorities - i.e. where the
>> serialNumbers come from - and from there, even BRA could have clearly
>> defined what the JOI values would be. This comprehensively resolves the
>> case, and without ambiguities.
>>
>> On Wed, Dec 4, 2019 at 4:47 PM Tim Hollebeek <tim.hollebeek at digicert.com>
>> wrote:
>>
>>> Could you concisely summarize your proposed solution?  I didn’t see
>>> anything beyond the need to be able to uniquely identify the registration
>>> jurisdiction, which is something Jeremy and I agree with.
>>>
>>>
>>>
>>> -Tim
>>>
>>>
>>>
>>> *From:* Ryan Sleevi <sleevi at google.com>
>>> *Sent:* Wednesday, December 4, 2019 4:38 PM
>>> *To:* Tim Hollebeek <tim.hollebeek at digicert.com>
>>> *Cc:* CA/B Forum Server Certificate WG Public Discussion List <
>>> servercert-wg at cabforum.org>; Jeremy Rowley <jeremy.rowley at digicert.com>
>>> *Subject:* Re: [Servercert-wg] [EXTERNAL] Clarification about EVG 9.2.4
>>>
>>>
>>>
>>> Do you not believe the solution I offered - which would go significantly
>>> further in addressing _Browser_ concerns - would work?
>>>
>>>
>>>
>>> I don't see your proposed solution meaningfully addressing the
>>> underlying problem? It's not that I disagree that definitional precision is
>>> useful, but I do not believe you can have sufficient definitional precision
>>> to guarantee interoperability, especially compared with substantially
>>> simpler, clearer approaches than finessing definitions.
>>>
>>>
>>>
>>> On Wed, Dec 4, 2019 at 3:56 PM Tim Hollebeek <tim.hollebeek at digicert.com>
>>> wrote:
>>>
>>> The problem is the old “is a canton a state or province” issue that
>>> we’ve discussed before.  The X.520 definition is far too broad, as it
>>> allows pretty much any geographical subdivision.  I don’t think we want to
>>> be auditing against “associated in some other important way.”
>>>
>>>
>>>
>>> ISO 3166-2 is a potential way to resolve it, and one we favor, but as it
>>> stands right now, the BRs are currently vague about what is or is not a
>>> state or province.  We should fix that.  In fact, it’s on my unofficial top
>>> ten list of things that needs to fixed about the BRs.
>>>
>>>
>>>
>>> One interesting question is whether there exist multiple identically
>>> named localities that register businesses in a single country, where a ISO
>>> 3166-2 state or province WOULD NOT disambiguate them.  That seems unlikely,
>>> but the world is weird.
>>>
>>>
>>>
>>> Stated another way: Is requiring a ISO 3166-2 state or province (if
>>> applicable), sufficient to disambiguate all jurisdictions where
>>> registration can happen at the locality level?  It certainly fixes the US
>>> case (I think: census designated places and unincorporated areas cannot
>>> register companies).
>>>
>>>
>>>
>>> -Tim
>>>
>>>
>>>
>>> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf
>>> Of *Ryan Sleevi via Servercert-wg
>>> *Sent:* Tuesday, December 3, 2019 4:48 PM
>>> *To:* Jeremy Rowley <jeremy.rowley at digicert.com>; CA/B Forum Server
>>> Certificate WG Public Discussion List <servercert-wg at cabforum.org>
>>> *Subject:* Re: [Servercert-wg] [EXTERNAL] Clarification about EVG 9.2.4
>>>
>>>
>>>
>>> I'm not sure I understand this objection, could you explain a little
>>> more?
>>>
>>>
>>>
>>> Are you suggesting there needs to be an X.520 reference to understand
>>> the semantics of the subdivision level?
>>>
>>>
>>>
>>> Specifically, X.520 describes it as:
>>>
>>> "The State or Province Name attribute type specifies a state or
>>> province. When used as a component of a directory name,
>>>
>>> it identifies a geographical subdivision in which the named object is
>>> physically located or with which it is associated in
>>> some other important way."
>>>
>>>
>>>
>>> and/or something like ISO 3166-2 defines it, which is the principal
>>> subdivision of a country aka the "first-level administrative domain"?
>>>
>>>
>>>
>>> Or is this only an objection with respect to the removal of "where the
>>> state or province regulates the registration of the entities at the
>>> locality level", which naturally leads to the state being the first-level
>>> administrative domain while locality representing a secondary, tertiary, or
>>> further subdivision within that superdivision?
>>>
>>>
>>>
>>> On Tue, Dec 3, 2019 at 4:17 PM Jeremy Rowley via Servercert-wg <
>>> servercert-wg at cabforum.org> wrote:
>>>
>>> State is not yet a defined term. We still need to get he ballot passed
>>> that defines what a state is as either part of this change or as a change
>>> that happens at the same time. Otherwise, you end up clarifying that we
>>> need “something” in the state field, but not specifying what that
>>> “something” is.
>>>
>>>
>>>
>>> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf
>>> Of *Dimitris Zacharopoulos (HARICA) via Servercert-wg
>>> *Sent:* Tuesday, December 3, 2019 12:18 PM
>>> *To:* servercert-wg at cabforum.org
>>> *Subject:* Re: [Servercert-wg] [EXTERNAL] Clarification about EVG 9.2.4
>>>
>>>
>>>
>>> Thanks everyone for your contributions to this topic.
>>>
>>> To summarize so far, there seems to be a majority preference to require
>>> the JoI-StateOrProvince to always be included in the subjectDN if the
>>> JoI-Locality exists, for disambiguation purposes.
>>>
>>> The current requirement: "And, the jurisdiction for the applicable
>>> Incorporating Agency or Registration Agency at the locality level MUST
>>> include the country and state or province information, where the state or
>>> province regulates the registration of the entities at the locality level,
>>> as well as the locality information."
>>>
>>> Proposed new requirement: "And, the jurisdiction for the applicable
>>> Incorporating Agency or Registration Agency at the locality level MUST
>>> include the country and state or province information, where the state
>>> or province regulates the registration of the entities at the locality level,
>>> as well as the locality information."
>>>
>>> However, I must admit that the same dilemma was in the Baseline
>>> Requirements when it was decided (long before I joined the Forum) that
>>> EITHER subject:stateOrProvinceName OR subject:localityName OR BOTH must be
>>> included. I assume this was for Countries that didn't have "States Or
>>> Provinces" but only "Localities". How is this going to play out in the JoI
>>> case? If we assume a country that doesn't have "States Or Provinces", it
>>> probably won't have "jurisdictionOfIncorporation" at a State Or Province
>>> level. How would this be resolved?
>>>
>>>
>>> Dimitris.
>>>
>>> On 2019-12-03 7:10 μ.μ., Kirk Hall via Servercert-wg wrote:
>>>
>>> Dimitris – When registration is done at the local level, it could be
>>> ambiguous if we allow CAs to only list *subject:jurisdictionLocalityName
>>> *and the *subject:jurisdictionCountryName, **but omit the**
>>> subject:jurisdictionStateOrProvinceName.*
>>>
>>>
>>>
>>> *I have listed below all the towns in the US named either “Salem” or
>>> “Springfield”  (thanks, Wikipedia) – there are a lot of them.  If place of
>>> registration in an EV certificate is just listed as “Salem, US” or
>>> “Springfield, US” there would be a potential disambiguation problem.*
>>>
>>>
>>>
>>> *I think Bruce Morton’s interpretation is correct – if the place of
>>> official registration is at the locality level, CAs should also include the
>>> State or Province (if any) and the Country.*
>>>
>>>
>>> United States[edit
>>> <https://en.wikipedia.org/w/index.php?title=Salem&action=edit&section=7&editintro=Template:Disambig_editintro>
>>> ]
>>>
>>> ·     Salem, Alabama <https://en.wikipedia.org/wiki/Salem,_Alabama>
>>>
>>> ·     Salem, Fulton County, Arkansas
>>> <https://en.wikipedia.org/wiki/Salem,_Fulton_County,_Arkansas>, a city
>>>
>>> ·     Salem, Saline County, Arkansas
>>> <https://en.wikipedia.org/wiki/Salem,_Saline_County,_Arkansas>, a
>>> census-designated place
>>>
>>> ·     Salem, Connecticut
>>> <https://en.wikipedia.org/wiki/Salem,_Connecticut>
>>>
>>> ·     Salem, Florida <https://en.wikipedia.org/wiki/Salem,_Florida>
>>>
>>> ·     Salem, Georgia <https://en.wikipedia.org/wiki/Salem,_Georgia>, in
>>> Upson County
>>>
>>> ·     Salem, Oconee County, Georgia
>>> <https://en.wikipedia.org/wiki/Salem,_Oconee_County,_Georgia>
>>>
>>> ·     Salem, Illinois <https://en.wikipedia.org/wiki/Salem,_Illinois>
>>>
>>> ·     Salem, Indiana <https://en.wikipedia.org/wiki/Salem,_Indiana>,
>>> city in Washington County
>>>
>>> ·     Salem, Adams County, Indiana
>>> <https://en.wikipedia.org/wiki/Salem,_Adams_County,_Indiana>,
>>> unincorporated place
>>>
>>> ·     Salem, Jay County, Indiana
>>> <https://en.wikipedia.org/wiki/Salem,_Jay_County,_Indiana>,
>>> unincorporated place
>>>
>>> ·     Salem, Union County, Indiana
>>> <https://en.wikipedia.org/wiki/Salem,_Union_County,_Indiana>,
>>> unincorporated place
>>>
>>> ·     Salem, Iowa <https://en.wikipedia.org/wiki/Salem,_Iowa>
>>>
>>> ·     Salem, Kentucky <https://en.wikipedia.org/wiki/Salem,_Kentucky>
>>>
>>> ·     Salem, Massachusetts
>>> <https://en.wikipedia.org/wiki/Salem,_Massachusetts>
>>>
>>> o   Salem Maritime National Historic Site
>>> <https://en.wikipedia.org/wiki/Salem_Maritime_National_Historic_Site>
>>>
>>> o   Salem witch trials
>>> <https://en.wikipedia.org/wiki/Salem_witch_trials>, a 1692–93 series of
>>> hearings and prosecutions
>>>
>>> o   Salem Harbor <https://en.wikipedia.org/wiki/Salem_Harbor>
>>>
>>> o   Salem Channel <https://en.wikipedia.org/wiki/Salem_Channel>, a part
>>> of the Salem Sound
>>>
>>> o   Salem (MBTA station)
>>> <https://en.wikipedia.org/wiki/Salem_(MBTA_station)>
>>>
>>> ·     Salem Township, Washtenaw County, Michigan
>>> <https://en.wikipedia.org/wiki/Salem_Township,_Washtenaw_County,_Michigan>
>>>
>>> ·     Salem, Missouri <https://en.wikipedia.org/wiki/Salem,_Missouri>,
>>> county seat of Dent County
>>>
>>> ·     Salem, Lewis County, Missouri
>>> <https://en.wikipedia.org/wiki/Salem,_Lewis_County,_Missouri>
>>>
>>> ·     Salem, Nebraska <https://en.wikipedia.org/wiki/Salem,_Nebraska>
>>>
>>> ·     Salem, New Hampshire
>>> <https://en.wikipedia.org/wiki/Salem,_New_Hampshire>
>>>
>>> ·     Salem, New Jersey
>>> <https://en.wikipedia.org/wiki/Salem,_New_Jersey>
>>>
>>> o   Salem Nuclear Power Plant
>>> <https://en.wikipedia.org/wiki/Salem_Nuclear_Power_Plant>
>>>
>>> o   Salem River <https://en.wikipedia.org/wiki/Salem_River>, a
>>> tributary of the Delaware River
>>>
>>> o   Port of Salem <https://en.wikipedia.org/wiki/Port_of_Salem>
>>>
>>> ·     Salem, New Mexico
>>> <https://en.wikipedia.org/wiki/Salem,_New_Mexico>
>>>
>>> ·     Salem, New York <https://en.wikipedia.org/wiki/Salem,_New_York>,
>>> town in Washington County
>>>
>>> o   Salem (hamlet), New York
>>> <https://en.wikipedia.org/wiki/Salem_(hamlet),_New_York>, within the
>>> town of Salem
>>>
>>> ·     Salem, an earlier name of Brocton, New York
>>> <https://en.wikipedia.org/wiki/Brocton,_New_York>, in Chautauqua County
>>>
>>> ·     Salem, North Carolina
>>> <https://en.wikipedia.org/wiki/Salem,_North_Carolina>,
>>> census-designated place in Burke County
>>>
>>> ·     Winston-Salem, North Carolina
>>> <https://en.wikipedia.org/wiki/Winston-Salem,_North_Carolina>, in
>>> Forsyth County
>>>
>>> o   Old Salem <https://en.wikipedia.org/wiki/Old_Salem>, a history
>>> museum in Winston-Salem
>>>
>>> ·     Salem, Ohio <https://en.wikipedia.org/wiki/Salem,_Ohio>
>>>
>>> ·     Salem, Oklahoma <https://en.wikipedia.org/wiki/Salem,_Oklahoma>
>>>
>>> ·     Salem, Oregon <https://en.wikipedia.org/wiki/Salem,_Oregon>, the
>>> state capital
>>>
>>> o   Salem Metropolitan Statistical Area
>>> <https://en.wikipedia.org/wiki/Salem_Metropolitan_Statistical_Area>,
>>> consisting of Marion and Polk counties
>>>
>>> o   Salem station (Oregon)
>>> <https://en.wikipedia.org/wiki/Salem_station_(Oregon)>, a railroad
>>> station
>>>
>>> ·     Salem, South Carolina
>>> <https://en.wikipedia.org/wiki/Salem,_South_Carolina>
>>>
>>> ·     Salem, South Dakota
>>> <https://en.wikipedia.org/wiki/Salem,_South_Dakota>, county seat of
>>> McCook County
>>>
>>> ·     Salem, Tennessee <https://en.wikipedia.org/wiki/Salem,_Tennessee>,
>>> an unincorporated community
>>>
>>> ·     Salem, Cherokee County, Texas
>>> <https://en.wikipedia.org/wiki/Salem,_Cherokee_County,_Texas>, an
>>> unincorporated community
>>>
>>> ·     Salem, Smith County, Texas
>>> <https://en.wikipedia.org/wiki/Salem,_Smith_County,_Texas>, an
>>> unincorporated community
>>>
>>> ·     Salem, Utah <https://en.wikipedia.org/wiki/Salem,_Utah>
>>>
>>> ·     Salem, Virginia <https://en.wikipedia.org/wiki/Salem,_Virginia>,
>>> an independent city adjacent to Roanoke
>>>
>>> ·     Salem, Virginia Beach, Virginia
>>> <https://en.wikipedia.org/wiki/Salem,_Virginia_Beach,_Virginia>, a
>>> neighborhood
>>>
>>> ·     Salem, West Virginia
>>> <https://en.wikipedia.org/wiki/Salem,_West_Virginia>, a city in
>>> Harrison County
>>>
>>> ·     Salem, Fayette County, West Virginia
>>> <https://en.wikipedia.org/wiki/Salem,_Fayette_County,_West_Virginia>,
>>> an unincorporated community
>>>
>>> ·     Salem, Wisconsin (disambiguation)
>>> <https://en.wikipedia.org/wiki/Salem,_Wisconsin_(disambiguation)>,
>>> several places in Wisconsin
>>>
>>>
>>>
>>>
>>> United States[edit
>>> <https://en.wikipedia.org/w/index.php?title=Springfield&action=edit&section=9&editintro=Template:Disambig_editintro>
>>> ]
>>>
>>> ·     Springfield, Alabama, unincorporated community
>>>
>>> ·     Springfield, Arkansas
>>> <https://en.wikipedia.org/wiki/Springfield,_Arkansas>
>>>
>>> ·     Springfield, California
>>> <https://en.wikipedia.org/wiki/Springfield,_California>
>>>
>>> ·     Springfield, Colorado
>>> <https://en.wikipedia.org/wiki/Springfield,_Colorado>
>>>
>>> ·     Springfield, Florida
>>> <https://en.wikipedia.org/wiki/Springfield,_Florida>, a city in Bay
>>> County
>>>
>>> ·     Springfield (Jacksonville)
>>> <https://en.wikipedia.org/wiki/Springfield_(Jacksonville)>, Florida, a
>>> neighborhood
>>>
>>> ·     Springfield, Georgia
>>> <https://en.wikipedia.org/wiki/Springfield,_Georgia>
>>>
>>> ·     Springfield, Idaho
>>> <https://en.wikipedia.org/wiki/Springfield,_Idaho>
>>>
>>> ·     Springfield, Illinois
>>> <https://en.wikipedia.org/wiki/Springfield,_Illinois>, the state
>>> capital of Illinois
>>>
>>> o   Springfield metropolitan area, Illinois
>>> <https://en.wikipedia.org/wiki/Springfield_metropolitan_area,_Illinois>
>>>
>>> ·     Springfield, LaPorte County, Indiana
>>> <https://en.wikipedia.org/wiki/Springfield,_LaPorte_County,_Indiana>
>>>
>>> ·     Springfield, Posey County, Indiana
>>> <https://en.wikipedia.org/wiki/Springfield,_Posey_County,_Indiana>
>>>
>>> ·     Springfield, Kentucky
>>> <https://en.wikipedia.org/wiki/Springfield,_Kentucky>
>>>
>>> ·     Springfield, Louisiana
>>> <https://en.wikipedia.org/wiki/Springfield,_Louisiana>
>>>
>>> ·     Springfield, Maine
>>> <https://en.wikipedia.org/wiki/Springfield,_Maine>
>>>
>>> ·     Springfield, Massachusetts
>>> <https://en.wikipedia.org/wiki/Springfield,_Massachusetts>, the first
>>> Springfield settled in America
>>>
>>> o   Springfield metropolitan area, Massachusetts
>>> <https://en.wikipedia.org/wiki/Springfield_metropolitan_area,_Massachusetts>,
>>> the most populous Metropolitan Springfield Area
>>>
>>> ·     Springfield, Michigan
>>> <https://en.wikipedia.org/wiki/Springfield,_Michigan>, a city in
>>> Calhoun County
>>>
>>> ·     Springfield, Minnesota
>>> <https://en.wikipedia.org/wiki/Springfield,_Minnesota>, in Brown County
>>>
>>> ·     Springfield, Missouri
>>> <https://en.wikipedia.org/wiki/Springfield,_Missouri>, the most
>>> populous city named Springfield in the United States
>>>
>>> o   Springfield metropolitan area, Missouri
>>> <https://en.wikipedia.org/wiki/Springfield_metropolitan_area,_Missouri>
>>>
>>> ·     Springfield, Nebraska
>>> <https://en.wikipedia.org/wiki/Springfield,_Nebraska>
>>>
>>> ·     Springfield, New Hampshire
>>> <https://en.wikipedia.org/wiki/Springfield,_New_Hampshire>
>>>
>>> ·     Springfield Township, Burlington County, New Jersey
>>> <https://en.wikipedia.org/wiki/Springfield_Township,_Burlington_County,_New_Jersey> (referred
>>> to as "Springfield")
>>>
>>> ·     Springfield Township, Union County, New Jersey
>>> <https://en.wikipedia.org/wiki/Springfield_Township,_Union_County,_New_Jersey> (referred
>>> to as "Springfield")
>>>
>>> ·     Springfield/Belmont, Newark, New Jersey
>>> <https://en.wikipedia.org/wiki/Springfield/Belmont,_Newark,_New_Jersey>,
>>> a neighborhood of Newark
>>>
>>> ·     Springfield, New York
>>> <https://en.wikipedia.org/wiki/Springfield,_New_York>
>>>
>>> ·     Springfield, Ohio
>>> <https://en.wikipedia.org/wiki/Springfield,_Ohio>
>>>
>>> ·     Springfield, Oregon
>>> <https://en.wikipedia.org/wiki/Springfield,_Oregon>
>>>
>>> ·     Springfield Township, Pennsylvania (disambiguation)
>>> <https://en.wikipedia.org/wiki/Springfield_Township,_Pennsylvania_(disambiguation)>
>>>
>>> ·     Springfield, South Carolina
>>> <https://en.wikipedia.org/wiki/Springfield,_South_Carolina>
>>>
>>> ·     Springfield, South Dakota
>>> <https://en.wikipedia.org/wiki/Springfield,_South_Dakota>
>>>
>>> ·     Springfield, Tennessee
>>> <https://en.wikipedia.org/wiki/Springfield,_Tennessee>
>>>
>>> ·     Springfield, Texas
>>> <https://en.wikipedia.org/wiki/Springfield,_Texas>, Jim Wells County
>>>
>>> ·     Springfield, former town and county seat of Limestone County,
>>> Texas, now part of Fort Parker State Park
>>> <https://en.wikipedia.org/wiki/Fort_Parker_State_Park>
>>>
>>> ·     Springfield, Vermont
>>> <https://en.wikipedia.org/wiki/Springfield,_Vermont>
>>>
>>> o   Springfield (CDP), Vermont
>>> <https://en.wikipedia.org/wiki/Springfield_(CDP),_Vermont>
>>>
>>> ·     Springfield, Virginia
>>> <https://en.wikipedia.org/wiki/Springfield,_Virginia>
>>>
>>> ·     Springfield, Albemarle County, Virginia
>>> <https://en.wikipedia.org/wiki/Springfield,_Albemarle_County,_Virginia>
>>>
>>> ·     Springfield (Coatesville, Virginia)
>>> <https://en.wikipedia.org/wiki/Springfield_(Coatesville,_Virginia)>, an
>>> historic home
>>>
>>> ·     Springfield, Page County, Virginia
>>> <https://en.wikipedia.org/wiki/Springfield,_Page_County,_Virginia>
>>>
>>> ·     Springfield, Westmoreland County, Virginia
>>> <https://en.wikipedia.org/wiki/Springfield,_Westmoreland_County,_Virginia>
>>>
>>> ·     Springfield, West Virginia
>>> <https://en.wikipedia.org/wiki/Springfield,_West_Virginia>
>>>
>>> ·     Springfield, Dane County, Wisconsin
>>> <https://en.wikipedia.org/wiki/Springfield,_Dane_County,_Wisconsin>, a
>>> town
>>>
>>> o   Springfield Corners, Wisconsin
>>> <https://en.wikipedia.org/wiki/Springfield_Corners,_Wisconsin>, an
>>> unincorporated community
>>>
>>> ·     Springfield, Jackson County, Wisconsin
>>> <https://en.wikipedia.org/wiki/Springfield,_Jackson_County,_Wisconsin>,
>>> a town
>>>
>>> ·     Springfield, Marquette County, Wisconsin
>>> <https://en.wikipedia.org/wiki/Springfield,_Marquette_County,_Wisconsin>,
>>> a town
>>>
>>> ·     Springfield, St. Croix County, Wisconsin
>>> <https://en.wikipedia.org/wiki/Springfield,_St._Croix_County,_Wisconsin>,
>>> a town
>>>
>>> ·     Springfield, Walworth County, Wisconsin
>>> <https://en.wikipedia.org/wiki/Springfield,_Walworth_County,_Wisconsin>,
>>> an unincorporated community
>>>
>>>
>>>
>>>
>>>
>>> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org>
>>> <servercert-wg-bounces at cabforum.org> *On Behalf Of *Dimitris
>>> Zacharopoulos (HARICA) via Servercert-wg
>>> *Sent:* Tuesday, December 3, 2019 12:29 AM
>>> *To:* Cynthia Revström <me at cynthia.re> <me at cynthia.re>; Jeremy Rowley
>>> <jeremy.rowley at digicert.com> <jeremy.rowley at digicert.com>; CA/B Forum
>>> Server Certificate WG Public Discussion List
>>> <servercert-wg at cabforum.org> <servercert-wg at cabforum.org>
>>> *Subject:* Re: [Servercert-wg] [EXTERNAL] Clarification about EVG 9.2.4
>>>
>>>
>>>
>>> Hi Cynthia,
>>>
>>> I think your comment is not so much related to the issue at hand. The
>>> language for JoI-Locality is the one that needs to be clarified. We are
>>> very clear about the other cases.
>>>
>>> My original interpretation was that no matter what, if an organization
>>> is registered at the locality level, the subjectDN MUST always include *subject:jurisdictionLocalityName
>>> *AND *subject:jurisdictionStateOrProvinceName* AND the
>>> *subject:jurisdictionCountryName.* After reading it more carefully I
>>> came to the conclusion that there is a different interpretation which was
>>> confirmed by Jeremy.
>>>
>>> Now, all we need to do is confirm that this was the original intent and
>>> if so, we may be able to improve this part of the EVG to make it more clear
>>> that it is allowed to include *subject:jurisdictionLocalityName*
>>> without a *subject:jurisdictionStateOrProvinceName* entry, for the case
>>> where the Country doesn't offer registration at the State or Province level.
>>>
>>> Is there anyone that objects to this interpretation?
>>>
>>>
>>> Thank you,
>>> Dimitris.
>>>
>>> On 2019-12-02 7:58 μ.μ., Cynthia Revström wrote:
>>>
>>> Hello,
>>>
>>> My interpretation would be that for example if we take Apple as an
>>> example, it would be jC=US, jST=California but no locality.
>>>
>>> I understand that this will get very complicated, as for example, in
>>> Sweden, limited companies are at a national level while for example sole
>>> proprietorships are at a county level.
>>>
>>> - Cynthia
>>>
>>>
>>>
>>> On Mon, Dec 2, 2019 at 6:50 PM Jeremy Rowley via Servercert-wg <
>>> servercert-wg at cabforum.org> wrote:
>>>
>>> I disagree as that's not what the language says. It says to include the
>>> state field if the state regulates registration of the locality. I can't
>>> speak to Toronto and how it incorporates entities (if it does), but I think
>>> the answer depends heavily on the locality, the type of entity, and how
>>> registration occurs.
>>> ------------------------------
>>>
>>> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> on behalf of
>>> Bruce Morton via Servercert-wg <servercert-wg at cabforum.org>
>>> *Sent:* Monday, December 2, 2019 10:45:32 AM
>>> *To:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>; CA/B Forum
>>> Server Certificate WG Public Discussion List <servercert-wg at cabforum.org
>>> >
>>> *Subject:* Re: [Servercert-wg] [EXTERNAL] Clarification about EVG 9.2.4
>>>
>>>
>>>
>>> I guess I am saying that you must include the jurisdiction level where
>>> the organization was registered. If the organization was registered at the
>>> locality level, then the certificate must include jL and jC. If the country
>>> has no states or provinces, then jST must not be used. If the country has
>>> states or provinces, then jST must be used, where jST is the state/province
>>> for jL.
>>>
>>>
>>>
>>> Let’s say that we have a company based in Toronto, Ontario, Canada; if
>>> it was registered in:
>>>
>>>    1. Canada, then the certificate must only have jC=CA
>>>    2. Ontario, then the certificate must only have jST=Ontario and
>>>    jC=CA. It cannot have jL=Toronto as the company was not registered by a
>>>    registrar at the locality level.
>>>    3. Toronto, then the certificate must have all 3, jL=Toronto,
>>>    jST=Ontario and jC=CA. jST must be included to help identity where the
>>>    locality is.
>>>
>>>
>>>
>>> Bruce
>>>
>>>
>>>
>>> *From:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>
>>> *Sent:* Monday, December 2, 2019 12:26 PM
>>> *To:* Bruce Morton <Bruce.Morton at entrustdatacard.com>; CA/B Forum
>>> Server Certificate WG Public Discussion List <servercert-wg at cabforum.org
>>> >
>>> *Subject:* Re: [EXTERNAL][Servercert-wg] Clarification about EVG 9.2.4
>>>
>>>
>>>
>>>
>>>
>>> On 2019-12-02 7:12 μ.μ., Bruce Morton wrote:
>>>
>>> Hi Dimitris,
>>>
>>>
>>>
>>> My interpretation is the following:
>>>
>>>
>>>
>>>    1. If the organization is registered at the country level, then the
>>>    certificate must include the *subject:jurisdictionCountryName.*
>>>    2. *If *the organization is *registered as the state/province level,
>>>    *then the certificate must include the
>>>    *subject:jurisdictionStateOrProvinceName* and the
>>>    *subject:jurisdictionCountryName.*
>>>    3. *If *the organization is *registered at the locality level, *then
>>>    the certificate must include the *subject:jurisdictionLocalityName*
>>>    and the *subject:jurisdictionCountryName;** and must include the **subject:jurisdictionStateOrProvinceName,
>>>    **only if the locality is in a state/province.*
>>>
>>>
>>> Hi Bruce, thanks for your reply.
>>>
>>> The first two are quite clear.
>>>
>>> The following:
>>> "*and must include the **subject:jurisdictionStateOrProvinceName, **only
>>> if the locality is in a state/province"*
>>>
>>> is not so clear to me. Perhaps you could elaborate with a couple of
>>> theoretical examples? I seems that the StateOrProvince is mixed with
>>> Locality in your description but I might have misunderstood.
>>>
>>>
>>> Dimitris.
>>>
>>>
>>>    1.
>>>
>>>
>>>
>>> *Bruce.*
>>>
>>>
>>>
>>> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org>
>>> <servercert-wg-bounces at cabforum.org> *On Behalf Of *Dimitris
>>> Zacharopoulos (HARICA) via Servercert-wg
>>> *Sent:* Monday, December 2, 2019 12:02 PM
>>> *To:* CA/B Forum Server Certificate WG Public Discussion List
>>> <servercert-wg at cabforum.org> <servercert-wg at cabforum.org>
>>> *Subject:* [EXTERNAL][Servercert-wg] Clarification about EVG 9.2.4
>>>
>>>
>>>
>>> *WARNING:* This email originated outside of Entrust Datacard.
>>> *DO NOT CLICK* links or attachments unless you trust the sender and
>>> know the content is safe.
>>> ------------------------------
>>>
>>>
>>> Dear members,
>>>
>>> I would like to ask for a clarification/interpretation about section
>>> 9.2.4 of the EV Guidelines and please forgive me if this has been discussed
>>> in the past.
>>> 9.2.4. Subject Jurisdiction of Incorporation or Registration Field
>>>
>>> "*Contents:* These fields MUST NOT contain information that is not
>>> relevant to the level of the Incorporating Agency or Registration Agency.
>>> For example, the Jurisdiction of Incorporation for an Incorporating Agency
>>> or Jurisdiction of Registration for a Registration Agency that operates at
>>> the country level MUST include the country information but MUST NOT include
>>> the state or province or locality information. Similarly, the jurisdiction
>>> for the applicable Incorporating Agency or Registration Agency at the state
>>> or province level MUST include both country and state or province
>>> information, but MUST NOT include locality information. And, the
>>> jurisdiction for the applicable Incorporating Agency or Registration Agency
>>> at the locality level MUST include the country and state or province
>>> information, where the state or province regulates the registration of the
>>> entities at the locality level, as well as the locality information.
>>> Country information MUST be specified using the applicable ISO country
>>> code. State or province or locality information (where applicable) for the
>>> Subject's Jurisdiction of Incorporation or Registration MUST be specified
>>> using the full name of the applicable jurisdiction."
>>>
>>> Is it allowed to include a *subject:jurisdictionLocalityName* without
>>> providing a *subject:jurisdictionStateOrProvinceName*?
>>>
>>> The requirement says "And, the jurisdiction for the applicable
>>> Incorporating Agency or Registration Agency at the locality level MUST
>>> include the country and state or province information, where the state or
>>> province regulates the registration of the entities at the locality level,
>>> as well as the locality information."
>>>
>>> In one interpretation, if there is no "state or province" that regulates
>>> the registration of entities but this registration is done at the locality
>>> level, then the *subject:jurisdictionStateOrProvinceName* can be
>>> omitted and only the *subject:jurisdictionLocalityName* is included
>>> along with the *subject:jurisdictionCountryName*. Is this an accurate
>>> and valid interpretation?
>>>
>>>
>>> Thank you,
>>> Dimitris.
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Servercert-wg mailing list
>>> Servercert-wg at cabforum.org
>>> http://cabforum.org/mailman/listinfo/servercert-wg
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>>
>>> Servercert-wg mailing list
>>>
>>> Servercert-wg at cabforum.org
>>>
>>> http://cabforum.org/mailman/listinfo/servercert-wg
>>>
>>>
>>>
>>> _______________________________________________
>>> Servercert-wg mailing list
>>> Servercert-wg at cabforum.org
>>> http://cabforum.org/mailman/listinfo/servercert-wg
>>>
>>> _______________________________________________
>> Servercert-wg mailing list
>> Servercert-wg at cabforum.org
>> http://cabforum.org/mailman/listinfo/servercert-wg
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20191204/3c74d32c/attachment-0001.html>

More information about the Servercert-wg mailing list