[cabf_validation] EVGL: Question about "overlapping" verification sources

Sun Apr 16 05:49:25 UTC 2023

I disagree that this is a problem or that the listings are ”improper”. In particular, I don’t really see what problem it creates to have multiple registration numbers for a single entity. I do agree with you that JOI certificate information needs updating to help make the information more useful. Note that we changed the EV language to allow registration sources in addition to jurisdiction of incorporation quite some time ago.  We also include “(or similar)” language in the section that specifies what CAs put into the JOI serial number field.  I think your assumption that Jurisdiction of Registration only applies to business entities is flawed. For private orgs under 11.2.1:  “Registration Number: Obtain the specific Registration Number assigned to the Applicant by the Incorporating or Registration Agency in the Applicant’s Jurisdiction of Incorporation or Registration. Where the Incorporating or Registration Agency does not assign a Registration Number, the CA SHALL obtain the Applicant’s date of Incorporation or Registration.” 

The intended purpose of JOI certificate information is to identify the legal entity responsible for the domain for the relying party. The idea was that the relying party could find and hold the entity behind the domain accountable for any bad actions. Having just a number and location in the JOI proved impossible to use, even before we expanded the scope to include registration numbers. Relying parties need to know exactly where to look in the jurisdiction to find the registration. Although in the US the registration number plus jurisdiction often proves sufficient (I can find the company registered in Delaware if I know the corporate ID),registration outside the US proved more nuance with many jurisdictions requiring several identifiers as part of the company registration and some registration numbers dependent on the specific entity type being registered. 

The problem isn’t with multiple numbers or different sources IMO – the problem you’re identify is that we don’t give users the source of the registration number in the certificate itself. If we included the source of the registration number in the actual certificate, Relying Parties could use that to find the company information instead of guessing where it came from. Making this information easier to find is far more useful that going through and having the CABF rigorously set rules about each jurisdiction – a task that the CABF isn’t really qualified to do. Including the source does something far better than restricting sources or unifying on JOI information – it gives Relying Parties direct knowledge on where they can find the company information in government records. 

From: Validation <validation-bounces at cabforum.org> On Behalf Of Pedro FUENTES via Validation
Sent: Saturday, April 15, 2023 11:18 AM
To: CABforum3 <validation at cabforum.org>
Subject: [cabf_validation] EVGL: Question about "overlapping" verification sources

Hello,

This is my first message in this list, so I’d like to apologise in case these topics are well known and discussed already. I had some exchanges with other members of the forum and it was mentioned the convenience of having this discussion here.

TL;DR: I think the (improper) disclosure of verification sources is messing up things and create a systemic problem. 

We are resuming EV issuance and we have been making some analysis and benchmarking on the different practices about EV certificate verification, and in particular about the verification of incorporation/registration schemas and the matching with the jurisdiction of registration/incorporation in some countries.

Things we found… given the same company “X” of category "Private Organization", existing in a certain country “C”, we can see:

*	CA 1 issues EV certificate to “X" with registration number N1, issued by the incorporation agency A1, and JOI assigned to country level. 
*	CA 2 issues EV certificate to “X" with same reg. number N1, issued by same agency A1, but different JOI, for example assigned to locality level. 
*	CA 3 issues EV certificate to “X" with registration number N2, issued by the incorporation agency A2, and JOI assigned to country level. 

So three different combinations of reg. number and JOI, and this even happens in different certificates issued to the same customer and same CA... Frankly speaking, I think something must be wrong here. 

First of all, I’d like to expose my assumptions, based on an strict reading of the EVGL.

*	The “Jurisdiction of Incorporation” is defined for the scope of private organizations and government entities.
*	The “Jurisdiction of registration” is defined for the scope of business entities only
*	The Jurisdiction of Incorporation/Registration is a characteristic of the organization, which is part of its identity, and the combination of the incorporation/registration number and the related jurisdiction is something that is unique for the organization (i.e. a company incorporated in an agency will be incorporated in a particular and fixed jurisdiction for that agency)
*	These identity characteristics of the organizations exist before they try to get an EV certificate, so the role of the CA is to retrieve and verify these attributes, but not to make them up on each verification

So, if the EVGL say that for “Private Organization” we need to consider the “Jurisdiction of Incorporation” (and not the Jurisdiction of Registration), and the Incorporation happens once and in a given Jurisdiction… How can it be possible that we have so much variation on combinations of registration numbers and JOI?

Going down the rabbit hole...

Section 11.1.3 sets the need for “Disclosure of Verification Sources”, but then it’s worded in terms of “Disclosure of Incorporating Agency or Registration Agency”, this already creates an issue, because verification sources aren’t necessarily registration or incorporation agencies, but these verification sources can be QGIS that are absolutely valid sources to obtain information about the company.

I’d have specially some questions about the potential side effect of using “overlapping verification sources”.

Let me put an example… In Switzerland we have the ZEFIX (Central Business Name Index), which is a federal resource to find information about the companies. So this is a QGIS that works at the country level, but the companies in Switzerland are incorporated in the cantons, and there are also cantonal registries (same agency where companies are incorporated actually) which allow to find the same information.

Therefore:

*	I can look for "WISeKey SA” in https://www.zefix.ch <https://url.avanan.click/v2/___https:/www.zefix.ch/___.YXAzOmRpZ2ljZXJ0OmE6bzo5NTgzZGNiMzNhMTNkODlmOTU3MzlkYjcwNGNjZmI0MDo2OmI3Zjk6YTFmN2I3Zjc5MGM3MDNkMWYzYjA5MjFlMTJmM2NiNzJhMjNhZGFmNjMzMmRmNzUzZWRiYWYxNTA1ODlmMGNjNTpoOkY>  and get information telling me that WISeKey is a company incorporated in the Canton of Geneva, and I can get there the registration number and other details
*	I can also look for “WISeKey SA” in https://www.ge.ch/recherche-entreprises-dans-registre-du-commerce-geneve <https://url.avanan.click/v2/___https:/www.ge.ch/recherche-entreprises-dans-registre-du-commerce-geneve___.YXAzOmRpZ2ljZXJ0OmE6bzo5NTgzZGNiMzNhMTNkODlmOTU3MzlkYjcwNGNjZmI0MDo2OjZiYWE6NGNmZDY0NTJiMjE3MTMyMzc2OGJkMmMxOTEwNWQ4YjY3OGFkOTMyMGRhMDgyN2FjOTZjMGQxNjdiOGYxZTg2NTpoOkY>  and get the same information

I’ve used two overlapping sources, one at country level, other at cantonal level, but obviously the JOI and registration numbers are the same, because it’s the same company registered in the same agency (Registry of Commerce of Geneva).

I could put another example… In Korea, companies are incorporated in the local court, but not all of these courts have public websites that provide tools to retrieve the information to do verifications, so the best approach is to look for the company information in the website of the Supreme Court (https://url.avanan.click/v2/___https://www.iros.go.kr___.YXAzOmRpZ2ljZXJ0OmE6bzo5NTgzZGNiMzNhMTNkODlmOTU3MzlkYjcwNGNjZmI0MDo2OjM0Yjc6OGFhZjQwZmU0MDg2MzM3ZWRmZTA5OGUyMWVlMmU3ZDhlODhiNGExZTFiNDYzNTY0Yjg0NDY5YmJlZjQwYzU2Mzp0OkY <https://url.avanan.click/v2/___https:/www.iros.go.kr___.YXAzOmRpZ2ljZXJ0OmE6bzo5NTgzZGNiMzNhMTNkODlmOTU3MzlkYjcwNGNjZmI0MDo2OjM0Yjc6OGFhZjQwZmU0MDg2MzM3ZWRmZTA5OGUyMWVlMmU3ZDhlODhiNGExZTFiNDYzNTY0Yjg0NDY5YmJlZjQwYzU2Mzp0OkY> ) and get there all the relevant information of the company, including the registration number and in which court was incorporated (which sets the JOI, that is never at country level). 

So, I have two considerations here:

*	Section 11.1.3 of the EVGL sets the need to indicate the accepted values for the JOI, for each verification source, but this requirement is quite complex to fulfil when we work with QGIS that operate at country level, but that can respond about incorporation at provincial and local levels.
*	Some CAs could assume that if they use a QGIS that operates at country level the JOI can be set at country level, and of they pull the (same) information from a local source, the JOI could be different… which is something against all logic, because if we check the information registered by SAME INCORPORATION/REGISTRATION agency, we need to identify the SAME JOI level for the same subscriber, independently of the QGIS that gives us the information. 

Here are my questions…

*	Has been discussed about setting some "common criteria", country by country, on how to process registration numbers and JOI in a consistent manner, so each CA doesn’t have to reinvent the wheel?
*	Why the wording of section 11.1.3 has as title “Disclosure of verification sources” but is not talking at all about disclosure of QGIS used by the CA, given the fact that not all registration or incorporation agencies provide useable verification means (e.g. web with search feature)?
*	How are CAs understanding that is fine the use of overlapping sources in a way that produces inconsistent JOI values for the same customer?

I could be fully misunderstanding the things here, so any help to let me get background the previous discussions to decide on the current approach would be greatly appreciated. 

Next Thursday 20th April I’d be participating in the sub-committee call for the first time… maybe this is something that can also be discussed there.

Thanks and regards,

Pedro

WISeKey SA

Pedro Fuentes
CSO - Trust Services Manager
Office: + 41 (0) 22 594 30 00
Mobile: + 41 (0) 791 274 790

Address: Avenue Louis-Casaï 58 | 1216 Cointrin | Switzerland

Stay connected with  <https://url.avanan.click/v2/___http:/www.wisekey.com/___.YXAzOmRpZ2ljZXJ0OmE6bzo5NTgzZGNiMzNhMTNkODlmOTU3MzlkYjcwNGNjZmI0MDo2OjFjMTM6M2Y0NGM0MzcwMTJmNjQ0MjMwZGUwMTkwODc0NDhlYTBmYmJkOGI3MWI0ZTQxYWUwNDRlNzIzNDE3Y2JiNGM0ODpoOkY> WISeKey

THIS IS A TRUSTED MAIL: This message is digitally signed with a WISeKey identity. If you get a mail from WISeKey please check the signature to avoid security risks

CONFIDENTIALITY: This email and any files transmitted with it can be confidential and it’s intended solely for the use of the individual or entity to which they are addressed. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. If you have received this email in error please notify the sender

DISCLAIMER: WISeKey does not warrant the accuracy or completeness of this message and does not accept any liability for any errors or omissions herein as this message has been transmitted over a public network. Internet communications cannot be guaranteed to be secure or error-free as information may be intercepted, corrupted, or contain viruses. Attachments to this e-mail are checked for viruses; however, we do not accept any liability for any damage sustained by viruses and therefore you are kindly requested to check for viruses upon receipt.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20230416/90569ed1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5221 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20230416/90569ed1/attachment-0001.p7s>