Re: Jurisdiction of incorporation validation issue

[Jakob Bohm via dev-security-policy]

[Please note that the way MS Outlook marks quoted text doesn't work well 
with Mozilla mail programs].

On 23/08/2019 22:37, Jeremy Rowley wrote:
>> 1. I believe the BRs and/or underlying technical standards are very
>> clear if the ST field should be a full name ("California") or an
>> abbreviation ("CA").
> 
> This is only true of the EV guidelines and only for Jurisdiction of
> Incorporation.  There is no formatting requirement for place of business.
> I think requiring a format would help make the data more useful as you
> could consume it easier en masse.
> 
X.520 (10/2012) says this:

6.3.3 State or Province Name

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.

An attribute value for State or Province Name is a string, e.g., S = "Ohio".

stateOrProvinceName ATTRIBUTE ::= {
  SUBTYPE OF   name
  WITH SYNTAX  UnboundedDirectoryString
  LDAP-SYNTAX  directoryString.
  LDAP-NAME{"st"}
  ID   id-at-stateOrProvinceName }

The Collective State or Province Name attribute type specifies a state or 
province name for a collection of entries.

collectiveStateOrProvinceName ATTRIBUTE ::= {
  SUBTYPE OF  stateOrProvinceName
  COLLECTIVE  TRUE
  ID  id-at-collectiveStateOrProvinceName }

[End of X.520 section 6.3.3]

For the location, (L and street attributes), X.520 is quite vague, but 
for the remarkably similar "postalAddress" attribute is defined in terms 
of the F.401 specification.


>> 2. The fact that a country has subdivisions listed in the general ISO
>> standard for country codes doesn't mean that those are always part of
>> the jurisdiction of incorporation and/or address.
> 
> Right. For the EV Guidelines, what matters is the Jurisdiction of 
> Registration or Jurisdiction of Incorporation as that is what is used> to 
> determine the Jurisdiction of Incorporation/Registration information,
> including what goes into the Registration Number Field.

As I mentioned, these are issues seen with other CAs blindly importing 
ISO 3166-2 into their systems.  For example one CA recently insisted 
that we filled the ST field with the equivalent of a county, because 
there was a political desire to eliminate having elected officials at 
the equivalent of state level, so someone in government probably went 
ahead and submitted an update to 3166-2 presuming success of that 
effort.

>   
> Incorporating Agency is defined as: In the context of a Private
> Organization, the government agency in the Jurisdiction of
> Incorporation under whose authority the legal existence of the entity
> is registered (e.g., the government agency that issues certificates 
> of formation or incorporation). In the context of a Government Entity,
> the entity that enacts law, regulations, or decrees establishing the
> legal existence of Government Entities
> 
> Registration Agency: A Governmental Agency that registers business
> information in connection with an entity's business formation or
> authorization to conduct business under a license, charter or other
> certification. A Registration Agency MAY include, but is not limited
> to (i) a State Department of Corporations or a Secretary of State;
> (ii) a licensing agency, such as a State Department of Insurance; or
> (iii) a chartering agency, such as a state office or department of
> financial regulation, banking or finance, or a federal agency such
> as the Office of the Comptroller of the Currency or Office of Thrift
> Supervision
> 
> This is broad. IMO we should reduce it to be the number listed on the> 
> certificate of formation/incorporation so there is consistency to what
> the registration means. We should also identify in the certificate the
> source of the registration number as it provides information to relying
> parties about the actual organization.

For most of the non-default numbering sources, the addition made in EVG 
1.7.0 appears to provide this.  Ideally, this should leave us with 
exactly one number-authority for each jurisdiction, org type and number 
format, subject of cause to random changes in local legislation and/or 
government practice.

For my example of C=DK, the numbering system for government entities has 
changed multiple times in recent decades.  In the 1970s there was only 
some tiny numbering systems such as 3 digit county numbers found in some 
obscure government records.  In the early 2000s it was decreed that all 
billing of government customers at all levels should use an XML format 
that identified each sub-entity by an EAN number (as in the 13 digit 
number system for product barcodes!), which was subsequently changed to 
many of the larger entities instead getting numbers from the companies 

Re: Jurisdiction of incorporation validation issue

[Ryan Sleevi via dev-security-policy]

On Fri, Aug 23, 2019 at 4:37 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> >> 1. I believe the BRs and/or underlying technical standards are very
>clear if the ST field should be a full name ("California") or an
>abbreviation ("CA").
>
> This is only true of the EV guidelines and only for Jurisdiction of
> Incorporation.  There is no formatting requirement for place of business. I
> think requiring a format would help make the data more useful as you could
> consume it easier en masse.
>
> >> 2. The fact that a country has subdivisions listed in the general ISO
>standard for country codes doesn't mean that those are always part of
>the jurisdiction of incorporation and/or address.
>
> Right. For the EV Guidelines, what matters is the Jurisdiction of
> Registration or Jurisdiction of Incorporation as that is what is used to
> determine the Jurisdiction of Incorporation/Registration information,
> including what goes into the Registration Number Field.
>
> Incorporating Agency is defined as: In the context of a Private
> Organization, the government agency in the Jurisdiction of
> Incorporation under whose authority the legal existence of the entity is
> registered (e.g., the government agency that issues
> certificates of formation or incorporation). In the context of a
> Government Entity, the entity that enacts law, regulations, or
> decrees establishing the legal existence of Government Entities
>
> Registration Agency: A Governmental Agency that registers business
> information in connection with an entity's business
> formation or authorization to conduct business under a license, charter or
> other certification. A Registration Agency MAY
> include, but is not limited to (i) a State Department of Corporations or a
> Secretary of State; (ii) a licensing agency, such as a
> State Department of Insurance; or (iii) a chartering agency, such as a
> state office or department of financial regulation,
> banking or finance, or a federal agency such as the Office of the
> Comptroller of the Currency or Office of Thrift
> Supervision
>
> This is broad. IMO we should reduce it to be the number listed on the
> certificate of formation/incorporation so there is consistency to what the
> registration means. We should also identify in the certificate the source
> of the registration number as it provides information to relying parties
> about the actual organization.
>

It's less broad when you also include the additional (included by
reference) definition for Government Agency

Government Agency: In the context of a Private Organization, the government
agency in the Jurisdiction of Incorporation
under whose authority the legal existence of Private Organizations is
established (e.g., the government agency that issued
the Certificate of Incorporation). In the context of Business Entities, the
government agency in the jurisdiction of operation
that registers business entities. In the case of a Government Entity, the
entity that enacts law, regulations, or decrees
establishing the legal existence of Government Entities.

So, for example, a Private Organization who registers with multiple
entities frequently will only obtain the Certificate of Incorporation from
a single one of those entities, reducing some of the ambiguity and
confusion.

That said, I agree, we should better clarify the expectations by moving to
a per-Jurisdiction allowlist of such organizations. This would also allow
creating and assigning codes to those entities, allowing is to supplant or
replace the existing Jurisdiction information with that entity code, which
would then unambiguously identify those attributes.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Jurisdiction of incorporation validation issue

[Ryan Sleevi via dev-security-policy]

On Fri, Aug 23, 2019 at 4:18 PM Jeremy Rowley 
wrote:

> > I can think of some incremental steps here:
>
> > - Disclosing exact detailed procedures via CP/CPS
>
>
>
> Maybe an addendum to the CPS. Or RPS. I’ll experiment and post something
> to see what the community thinks.
>

Yup. I've seen plenty of CP/CPSes that place extensive detail within
appendices of their CP/CPS. The important part of having this within the
CP/CPS is the (albeit limited) binding to the audit procedure. After all,
the objective of an audit is to ensure the CP/CPS is fairly stated with
respect to the actual operations practiced, across several dimensions, and
so having that allowlist clearly documented, versioned, and audited helps
provide a degree of assurance to RPs that simply placing in the RPS
wouldn't necessarily achieve.


> >  - An emphasis should be on allowlisting. Anything not on the allowlist
> *should* be an exceptional thing.
>
>
>
> This we actually have internally. Or are you saying across the industry?
> The allow list internally is something prevetted by compliance and legal.
> We’re currently (prompted by a certificate problem report) reviewing the
> entire allowed list to see what’s there and taking anything off that I
> don’t like. Basically we’re using your suggestion of
> https://www.gleif.org/en/about-lei/code-lists/gleif-registration-authorities-list
> plus a couple of lists for banking (like FDIC).
>

Ideally, yes, I'd like to see a transition from ad-hoc interpretations into
formalized lists, whether it be through browser policy or through the
Baseline Requirements/EV Guidelines.

I'd love to see a CA take their existing list and propose it, which would
allow for discussion and rationale (e.g. if there are organizations that
should or should not be on that list), but would also help formalize it as
an industry. DigiCert documenting in its CP/CPS is a good first step.
Better would be DigiCert proposing a ballot, although I'm sure members of
the browser community would be happy to propose a ballot on the basis of
whomever publishes their list first.

Regardless, however, the mere act of publishing that list helps develop
tooling to externally vet compliance and consistency with those statements,
and that might amortize some of the internal tooling costs.

 > - For example, stating DigiCert will always use a State from ISO 3166-2
> makes it clear, and also makes it something verifiable (i.e. someone can
> implement an
>
> automated check)
>
>
>
> Maybe what we’ll do is keep a running list of the checks. We’re finalizing
> on spelling out all states. No abbreviations.  This is something we can
> specify in our RPS – how it looks for each field.
>

Why not CP/CPS? This is somewhat a canonical example of the purpose of a
Certificate Profile as specified within a Certificate Policy. Several CAs,
such as Sectigo and SwissSign, include within their CP extensive profiles
of all certificate types they issue. That's somewhat a model for other CAs
to consider and examine.

You can see Appendix C of Sectigo's CP/CPS, or 7.1 of SwissSign.


>  > - Similarly, enumerating the registries used makes it possible, in many
> cases, to automatically check the serialNumber for both format and accuracy
>
>
>
> Checking the registration number for format and accuracy is something I
> proposed for the new project, but I wasn’t sure how feasible it was
> considering the wide variation. You end up with a lot of different numbers.
> I wonder if you could get it to range for formats? That would certainly be
> doable while adding some layers of protection.
>

I agree, it's going to vary based on the registry. However, enumerating the
registries is the first step to being able to enumerate the numbers and
formats. For example, one of the problem reports for a recent set of issues
went ahead and started a opensource GitHub repository to try and collect
some of that information, based on Registry -
https://github.com/bitcynth/company-number-formats/blob/master/formats.md -
so we certainly know it's possible.


> >- Modifying the CA/B Forum documents to formalize those processes, by
> explicitly removing the ambiguity or CA discretion. DigiCert's done well
> here in the past, removing validation methods like 3.2.2.4.1 / 3.2.2.4.5
> due to their misuse and danger
>
>
>
> One ballot I do want to pass is adding a field for the JOI entity
> information. This way everyone can see where the registration number
> originated. Short of a formalized CAB forum list of permitted entities
> (which is also on the table), this would make it very easy to have a
> conversation on whether what the registration number means. There’s
> probably others, but that’s a request that’s been surfacing a few times.
>

I think I'd invert that priority list. I hear that some CA customers,
particularly in the banking sector, get exceptionally nervous for any
change to certificate profiles, even for something as simple and
uncontroversial as a validity period, so 

RE: Jurisdiction of incorporation validation issue

[Jeremy Rowley via dev-security-policy]

>> 1. I believe the BRs and/or underlying technical standards are very
   clear if the ST field should be a full name ("California") or an
   abbreviation ("CA").

This is only true of the EV guidelines and only for Jurisdiction of 
Incorporation.  There is no formatting requirement for place of business. I 
think requiring a format would help make the data more useful as you could 
consume it easier en masse.

>> 2. The fact that a country has subdivisions listed in the general ISO
   standard for country codes doesn't mean that those are always part of
   the jurisdiction of incorporation and/or address.

Right. For the EV Guidelines, what matters is the Jurisdiction of Registration 
or Jurisdiction of Incorporation as that is what is used to determine the 
Jurisdiction of Incorporation/Registration information, including what goes 
into the Registration Number Field. 
 
Incorporating Agency is defined as: In the context of a Private Organization, 
the government agency in the Jurisdiction of
Incorporation under whose authority the legal existence of the entity is 
registered (e.g., the government agency that issues
certificates of formation or incorporation). In the context of a Government 
Entity, the entity that enacts law, regulations, or
decrees establishing the legal existence of Government Entities

Registration Agency: A Governmental Agency that registers business information 
in connection with an entity's business
formation or authorization to conduct business under a license, charter or 
other certification. A Registration Agency MAY
include, but is not limited to (i) a State Department of Corporations or a 
Secretary of State; (ii) a licensing agency, such as a
State Department of Insurance; or (iii) a chartering agency, such as a state 
office or department of financial regulation,
banking or finance, or a federal agency such as the Office of the Comptroller 
of the Currency or Office of Thrift
Supervision

This is broad. IMO we should reduce it to be the number listed on the 
certificate of formation/incorporation so there is consistency to what the 
registration means. We should also identify in the certificate the source of 
the registration number as it provides information to relying parties about the 
actual organization. 

>> 3. The fact that a government data source lists the incorporation
   locality of a company, doesn't mean that this locality detail is
   actually a relevant part of the jurisdictionOfIncorporation.  This
   essentially depends if the rules in that country ensure uniqueness of
   both the company number and company name at a higher jurisdiction
   level (national or state) to the same degree as at the lower level.
For example, in the US the company name "Stripe" is not unique
   nationwide.

Right - this depends on where the formation/registration occurs. That's 
captured in the EV guidelines.

___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Jurisdiction of incorporation validation issue

[Jeremy Rowley via dev-security-policy]

>>  I'm a little nervous about encouraging wide use of OCR. You may recall at 
>> least one CA was bit by an issue in which their OCR system misidentified 
>> letters - https://bugzilla.mozilla.org/show_bug.cgi?id=1311713

>> That's why I was keen to suggest technical solutions which would verify and 
>> cross-check. My main concern here would be, admittedly, to ensure the 
>> serialNumber itself is reliably entered and detected. Extracting that from a 
>> system, such as you could due via an Extension when looking at, say, the 
>> Handelsregister, is a possible path to reduce both human transcription and 
>> machine-aided transcription issues.

Right – and the OCR there is just to make the initial assessment. The idea is 
to still require validation staff to select the appropriate fields. I like the 
idea of cross-checking. Maybe what we can also do is tie into a non-primary 
source (Like D or something) to confirm the  jurisdiction information. We’ll 
have to evaluate it, but I like the idea of cross-checking against a reliable 
source that has an API even if we can’t use the source as our primary source 
for that information. I’ll need to investigate, but it should be possible for 
most of EU and the US. Less so for the middle east and Asia.

>> Of course, alternative ways of cross-checking and vetting that data may 
>> exist. Alternatively, it may be that the solution would be to only allowlist 
>> the use of validation sources that made their datasets machine readable - 
>> this would/could address a host of issues in terms of quality. I'm 
>> admittedly not sure the extent to which organizations still rely on legacy 
>> paper trails, and I understand they're still unfortunately common in some 
>> jurisdictions, particularly in the Asia/Pacific region, so it may not be as 
>> viable.

Yeah – that mean you basically can’t issue in middle east and mot of Asia. 
Japan would still work. China I’d have to look. Like I said, there could be 
non-primary sources that could correlate. We’ll spec that out as we get closer 
and see what we can do for cross-correlation. May be that we can have enough 
somethings world-wide that you can always confirm registration with a secondary 
source.

The process right now is we right a script based on things we can think of that 
might be wrong (abbreviated states, the word “some” in the state field, etc). 
We usually pull a sampling of a couple thousand certs and review those to see 
if we can find anything wrong that can help identify other patterns. We’re in 
the middle of doing that for the JOI issues.  What would be WAY better is if we 
had rule sets for validation information (similar to cablint) that checked 
validation information and how it is stored in our system and made these rule 
sets run on the complete data every time we change something in validation. 
Right now, we build quick and dirty checks that run one time when we have an 
incident. That’s not great as it’s a lot of stuff we can’t reuse. What we 
should do is build something (that crossing my fingers we can open source and 
share) that will be a library of checks on validation information. Sure, it’ll 
take a lot of configuration to work with how other CAs store data, but one 
thing we’ve seen problems with is that changes in one system lead to 
un-expected potential non-compliances in others. Having something  that works 
cross-functionally throughout the system helps.


  *   Hugely, and this is exactly the kind of stuff I'm excited to see CAs 
discussing and potentially sharing. I think there are some opportunities for 
incremental improvements here that may be worth looking at, even before that 
final stage.


  *   I would argue a source of (some of) these problems is ambiguity that is 
left to the CA's discretion. For example, is the state abbreviated or not? Is 
the jurisdictional information clear?  Who are the authorized registries for a 
jurisdiction that a CA can use?

I think that’s definitely true. There’s lots of ambiguities in the EV 
guidelines. You and I were talking about Incorporating Agencies, which is not 
really defined as incorporating agencies. Note that CAs can use Incorporating 
Agencies or Registration Agencies to confirm identity, which is very broad, but 
there is no indication in the certificate what that means.

> I can think of some incremental steps here:
> - Disclosing exact detailed procedures via CP/CPS

Maybe an addendum to the CPS. Or RPS. I’ll experiment and post something to see 
what the community thinks.

>  - An emphasis should be on allowlisting. Anything not on the allowlist 
> *should* be an exceptional thing.

This we actually have internally. Or are you saying across the industry? The 
allow list internally is something prevetted by compliance and legal. We’re 
currently (prompted by a certificate problem report) reviewing the entire 
allowed list to see what’s there and taking anything off that I don’t like. 
Basically we’re using your suggestion of 

Re: Jurisdiction of incorporation validation issue

[Ryan Sleevi via dev-security-policy]

On Fri, Aug 23, 2019 at 2:00 PM Jeremy Rowley 
wrote:

>
>
>- Could you highlight a bit more your proposal here? My understanding
>is that, despite the Handelsregister ("Commercial Register") being
>available at a country level, it's further subdivided into a list of
>couunty or region - e.g. the Amtsgericht Herne ("Local Court Herne").
>
>
>
>- It sounds like you're still preparing to allow for manual/human
>input, and simply consistency checking. Is there a reason to not use an
>allowlist-based approach, in which your Registration Agents may only select
>from an approved list of County/Region/Locality managed by your Compliance
>Team?
>
>
>
>- That, of course, still allows for human error. Using the excellent
>example of the Handelsregister, perhaps you could describe a bit more the
>flow a Validation Specialist would go through. Are they expected to examine
>a faxed hardcopy? Or do they go to handelsregister.de and look up via
>the registration code?
>
>
>
>- I ask, because it strikes me that this could be an example where a
>CA could further improve automation. For example, it's not difficult to
>imagine that a locally-developed extension could know the webpages used for
>validation of the information, and extract the salient info, when that
>information is not easily encoded in a URL. For those not familiar,
>Handelsregister encodes the parameters via form POST, a fairly common
>approach for these company registers, and thus makes it difficult to store
>a canonical resource URL for, say, a server-to-server retrieval. This would
>help you quickly and systematically identify the relevant jurisdiction and
>court, and in a way that doesn't involve human error.
>
>
>
> I did not know that about Handelsregister. So that’s good info.  Right
> now, the validation staff selects Handelsregister as the source, the system
> retrieves the information, the staff then selects the jurisdiction
> information and enters the registration information. Germany is locked in
> as the country of verification (because Handelsregister is the source), but
> the staff enters the locality/state type information as the system doesn’t
> know which region is correct.
>
>
>
> The idea is that everywhere we can, the process should automatically fill
> in jurisdiction information for the validation staff so no typing is
> required. This is being done in three parts:
>
>1. Immediate (aka Stop the Hurt): The first step is to put the GeoCode
>check in place to ensure that no matter what there will be valid
>non-mispelled information in the certificate. There will still be
>user-typed information during the phase since this phase is Aug 18 2019.
>The system will work exactly as it does now except that the JOI information
>will run through the GeoCode system to verify that yes, this information
>isn’t wrong. If wrong, the system won’t allow the cert to be approved.  At
>this point, no new issues should occur, but I won’t be satisfied as its way
>too manual – and the registration number is still a manual entry. That
>needs to change.
>2. Intermediate (aka Neuter the Staff): During this process we plan to
>eliminate typing of sources. Instead, the sources will be picklists based
>on jurisdiction. This means that if you select Germany and the company type
>is an LLC, you get a list of available sources. Fool proof-ish. There’s
>still a copy/paste or manual entry of the registration number. For those
>sources that do provide an API, we can tie into the API, retrieve the
>documentation, and populate the information.  We want to do that as well,
>provided it doesn’t throw off phase 3. Since the intermediate solution is
>also a stop-gap to the final solution, we want it to be a substantial
>improvement but one that doesn’t impede our final destination.
>3. The refactor (aka Documents r Us): This is still very much being
>specc’ed but we’re currently thinking we want to evolve the system to a
>document system. Right now the system works on checklists. For JOI, you
>enter the JOI part, select a document (or two) that you’ll to verify JOI
>and then transfer information to the system from the document. The revamp
>moves it to where you have the document and specify on the document which
>parts of the document apply to the organization. For example, you specify
>on the document that a number is a registration number or that a name is an
>org name, highlighting the info.  With auto-detection of the fields (just
>based on key words), you end up with a pretty dang automated system. The
>validation staff is there to review for accuracy and highlight things that
>might be missed. Hence, no typing or specifying any information. It’s all
>directly from the source.
>
>
>
> Naming conventions also not approved yet. Since the engineers 

RE: Jurisdiction of incorporation validation issue

[Jeremy Rowley via dev-security-policy]

  *   Could you highlight a bit more your proposal here? My understanding is 
that, despite the Handelsregister ("Commercial Register") being available at a 
country level, it's further subdivided into a list of couunty or region - e.g. 
the Amtsgericht Herne ("Local Court Herne").


  *   It sounds like you're still preparing to allow for manual/human input, 
and simply consistency checking. Is there a reason to not use an 
allowlist-based approach, in which your Registration Agents may only select 
from an approved list of County/Region/Locality managed by your Compliance Team?


  *   That, of course, still allows for human error. Using the excellent 
example of the Handelsregister, perhaps you could describe a bit more the flow 
a Validation Specialist would go through. Are they expected to examine a faxed 
hardcopy? Or do they go to handelsregister.de and 
look up via the registration code?



  *   I ask, because it strikes me that this could be an example where a CA 
could further improve automation. For example, it's not difficult to imagine 
that a locally-developed extension could know the webpages used for validation 
of the information, and extract the salient info, when that information is not 
easily encoded in a URL. For those not familiar, Handelsregister encodes the 
parameters via form POST, a fairly common approach for these company registers, 
and thus makes it difficult to store a canonical resource URL for, say, a 
server-to-server retrieval. This would help you quickly and systematically 
identify the relevant jurisdiction and court, and in a way that doesn't involve 
human error.

I did not know that about Handelsregister. So that’s good info.  Right now, the 
validation staff selects Handelsregister as the source, the system retrieves 
the information, the staff then selects the jurisdiction information and enters 
the registration information. Germany is locked in as the country of 
verification (because Handelsregister is the source), but the staff enters the 
locality/state type information as the system doesn’t know which region is 
correct.

The idea is that everywhere we can, the process should automatically fill in 
jurisdiction information for the validation staff so no typing is required. 
This is being done in three parts:

  1.  Immediate (aka Stop the Hurt): The first step is to put the GeoCode check 
in place to ensure that no matter what there will be valid non-mispelled 
information in the certificate. There will still be user-typed information 
during the phase since this phase is Aug 18 2019. The system will work exactly 
as it does now except that the JOI information will run through the GeoCode 
system to verify that yes, this information isn’t wrong. If wrong, the system 
won’t allow the cert to be approved.  At this point, no new issues should 
occur, but I won’t be satisfied as its way too manual – and the registration 
number is still a manual entry. That needs to change.
  2.  Intermediate (aka Neuter the Staff): During this process we plan to 
eliminate typing of sources. Instead, the sources will be picklists based on 
jurisdiction. This means that if you select Germany and the company type is an 
LLC, you get a list of available sources. Fool proof-ish. There’s still a 
copy/paste or manual entry of the registration number. For those sources that 
do provide an API, we can tie into the API, retrieve the documentation, and 
populate the information.  We want to do that as well, provided it doesn’t 
throw off phase 3. Since the intermediate solution is also a stop-gap to the 
final solution, we want it to be a substantial improvement but one that doesn’t 
impede our final destination.
  3.  The refactor (aka Documents r Us): This is still very much being specc’ed 
but we’re currently thinking we want to evolve the system to a document system. 
Right now the system works on checklists. For JOI, you enter the JOI part, 
select a document (or two) that you’ll to verify JOI and then transfer 
information to the system from the document. The revamp moves it to where you 
have the document and specify on the document which parts of the document apply 
to the organization. For example, you specify on the document that a number is 
a registration number or that a name is an org name, highlighting the info.  
With auto-detection of the fields (just based on key words), you end up with a 
pretty dang automated system. The validation staff is there to review for 
accuracy and highlight things that might be missed. Hence, no typing or 
specifying any information. It’s all directly from the source.

Naming conventions also not approved yet. Since the engineers watch this forum, 
they’ll probably throw things at me when they see the code names.


  *   I'm curious how well that approach generalizes, and/or what challenges 
may exist. I totally understand that for registries which solely use hard 
copies, this is a far more difficult task 

Re: Jurisdiction of incorporation validation issue

[Jakob Bohm via dev-security-policy]

On 23/08/2019 04:29, Jeremy Rowley wrote:

I posted this tonight: https://bugzilla.mozilla.org/show_bug.cgi?id=1576013. It's sort of 
an extension of the "some-state" issue, but with the incorporation information 
of an EV cert.  The tl;dr of the bug is that sometimes the information isn't perfect 
because of user entry issues.

What I was hoping to do is have the system automatically populate the 
jurisdiction information based on the incorporation information. For example, 
if you use the Delaware secretary of state as the source, then the system 
should auto-populate Delaware as the State and US as the jurisdiction. And it 
does...with some.

However, you do you have jurisdictions like Germany that consolidate incorporation 
information to www.handelsregister.de so you 
can't actually tell which area is the incorporation jurisdiction until you do a 
search. Thus, the fields to allow some user input. That user input is what hurts.   
In the end, we're implementing an address check that verifies the 
locality/state/country combination.

The more interesting part (in my opinion) is how to find and address these 
certs. Right now, every time we have an issue or whenever a guideline changes 
we write a lot of code, pull a lot of certs, and spend a lot of time reviewing. 
Instead of doing this every time, we're going to develop a tool that will run 
automatically every time we change a validation rule to find everything else 
that will fail the new update rules. IN essence, building unit tests on the 
data. What I like about this approach is it ends up building a system that lets 
us see how all the rule changes interplay since sometimes they may intercept in 
weird ways. It'll also let us easier measure impact of changes on the system. 
Anyway, I like the idea. Thought I'd share it here to get feedback and 
suggestions for improvement. Still in spec phase, but I can share more info as 
it gets developed.

Thanks for listening.



Additional issues seen at some CAs (not necessarily Digicert):

1. I believe the BRs and/or underlying technical standards are very
  clear if the ST field should be a full name ("California") or an
  abbreviation ("CA").

2. The fact that a country has subdivisions listed in the general ISO
  standard for country codes doesn't mean that those are always part of
  the jurisdiction of incorporation and/or address.

3. The fact that a government data source lists the incorporation
  locality of a company, doesn't mean that this locality detail is
  actually a relevant part of the jurisdictionOfIncorporation.  This
  essentially depends if the rules in that country ensure uniqueness of
  both the company number and company name at a higher jurisdiction
  level (national or state) to the same degree as at the lower level.
   For example, in the US the company name "Stripe" is not unique
  nationwide.

In practice this means that validation specialists need to draw up
various common facts for each country served by a CA, and keep those up 
to date.


As a non-expert citizen, I believe the proper details for my own country 
(C=DK) are:


1. ST= should be Greenland or Grønland (Greenland self-governing
  territory aka .gl), Faeroe Islands or Færøerne (Faeroe Islands self-
  governing territory aka .fo) or omitted (main country, under the
  central government).  Other territories were lost more than 100 years
  ago and can't occur in current certificate subjects.

2. Company numbers for the main country are numbers from the online CVR
  database, they are the same as VAT numbers except: No leading DK, not
  all companies have a VAT registration and not all VAT registrations
  are companies (some are actual the social security numbers of the
  owners of sole proprietorships).  Other private organizations are
  often listed in CVR too.

3. Government institutions at all levels have numbers from a database
  used for electronic billing in OIO UBL XML formats.  Some of those
  numbers are CVR numbers (like for companies), some are SE numbers and
  some are EAN/GLN numbers.

4. Postal codes are 4 digits (leading 0 only occurs in some special
  cases, DK prefix is added on international physical mail, but is not
  actually part of the postal code).

5. The new code number types added in EV 1.7.0 require additional
  research on how they officially map to Danish public administration.

But a CA validation team should research this further to set up proper
templates and scripts for validating EV/OV/IV applicants claiming C=DK.


Enjoy

Jakob
--
Jakob Bohm, CIO, Partner, WiseMo A/S.  https://www.wisemo.com
Transformervej 29, 2860 Søborg, Denmark.  Direct +45 31 13 16 10
This public discussion message is non-binding and may contain errors.
WiseMo - Remote Service Management for PCs, Phones and Embedded
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org

Re: Jurisdiction of incorporation validation issue

[Ryan Sleevi via dev-security-policy]

On Thu, Aug 22, 2019 at 10:29 PM Jeremy Rowley via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I posted this tonight:
> https://bugzilla.mozilla.org/show_bug.cgi?id=1576013. It's sort of an
> extension of the "some-state" issue, but with the incorporation information
> of an EV cert.  The tl;dr of the bug is that sometimes the information
> isn't perfect because of user entry issues.
>
> What I was hoping to do is have the system automatically populate the
> jurisdiction information based on the incorporation information. For
> example, if you use the Delaware secretary of state as the source, then the
> system should auto-populate Delaware as the State and US as the
> jurisdiction. And it does...with some.
>
> However, you do you have jurisdictions like Germany that consolidate
> incorporation information to www.handelsregister.de<
> http://www.handelsregister.de> so you can't actually tell which area is
> the incorporation jurisdiction until you do a search. Thus, the fields to
> allow some user input. That user input is what hurts.   In the end, we're
> implementing an address check that verifies the locality/state/country
> combination.
>

Could you highlight a bit more your proposal here? My understanding is
that, despite the Handelsregister ("Commercial Register") being available
at a country level, it's further subdivided into a list of couunty or
region - e.g. the Amtsgericht Herne ("Local Court Herne").

It sounds like you're still preparing to allow for manual/human input, and
simply consistency checking. Is there a reason to not use an
allowlist-based approach, in which your Registration Agents may only select
from an approved list of County/Region/Locality managed by your Compliance
Team?

That, of course, still allows for human error. Using the excellent example
of the Handelsregister, perhaps you could describe a bit more the flow a
Validation Specialist would go through. Are they expected to examine a
faxed hardcopy? Or do they go to handelsregister.de and look up via the
registration code?

I ask, because it strikes me that this could be an example where a CA could
further improve automation. For example, it's not difficult to imagine that
a locally-developed extension could know the webpages used for validation
of the information, and extract the salient info, when that information is
not easily encoded in a URL. For those not familiar, Handelsregister
encodes the parameters via form POST, a fairly common approach for these
company registers, and thus makes it difficult to store a canonical
resource URL for, say, a server-to-server retrieval. This would help you
quickly and systematically identify the relevant jurisdiction and court,
and in a way that doesn't involve human error.

I'm curious how well that approach generalizes, and/or what challenges may
exist. I totally understand that for registries which solely use hard
copies, this is a far more difficult task than it needs to be, and thus an
element of human review. However, depending on how prevalent the hardcopy
vs online copy is, we might be able to pursue automation for more, and thus
increase the stringency for the exceptions that do involve physical copies.


> The more interesting part (in my opinion) is how to find and address these
> certs. Right now, every time we have an issue or whenever a guideline
> changes we write a lot of code, pull a lot of certs, and spend a lot of
> time reviewing. Instead of doing this every time, we're going to develop a
> tool that will run automatically every time we change a validation rule to
> find everything else that will fail the new update rules. IN essence,
> building unit tests on the data. What I like about this approach is it ends
> up building a system that lets us see how all the rule changes interplay
> since sometimes they may intercept in weird ways. It'll also let us easier
> measure impact of changes on the system. Anyway, I like the idea. Thought
> I'd share it here to get feedback and suggestions for improvement. Still in
> spec phase, but I can share more info as it gets developed.
>

This sounds like a great idea, and would love to know more details here.
For example, what's the process now for identifying these
jurisdictionOfIncorporation issues? How would it improve or change with
this system?

You describe it as "validation rule" changes - and I'm not sure if you're
talking about the BRs (i.e. "we validated this org at time X") or something
else. I'm not sure whether you're adding additional data, or formalizing
checks on existing data. More details here could definitely help try and
generalize it, and might be able to formalize it as a best practice.
Alternatively, even if we can't formalize it as a requirement, it may be
able to use as the basis when evaluating potential impact or cost of
changes (to policy or the BRs) in the future. That is, "any CA that has
implemented (system you describe) should be able to provide quantifiable
data