[cabf_validation] [EXTERNAL]-RE: EVGL: Question about "overlapping" verification sources

Sun Apr 16 18:11:23 UTC 2023

Hi Jeremy,

Thanks a lot for participating in the debate and your insights. I think you raise quite interesting points, but I must say that there are part of it that I fail to correlate to what is written in the EVGL.

Let me insert some comments in your mail.

BR/P

> On 16 Apr 2023, at 07:49, Jeremy Rowley <jeremy.rowley at digicert.com> wrote:
> 
> 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 don’t see as a problem “per se” having multiple valid registration numbers for a single entity, as we could understand that an entity can be registered in several agencies. My main concern in this case is to have a given subscriber, registered in a given agency with a registration number, and present inconsistent JOI in each of their certificates.

Said so, I still think that most (if not all) countries set clearly a process to incorporate an organization and what is the incumbent registry, and we should do our best to understand the incorporation process and use that incumbent registry and not being too “creative” and use secondary registration agencies.

> 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.” 

For me the problem is that Section 4 of the EVGL make explicit definitions of what is the jurisdiction of incorporation and jurisdiction of registration, and each is also explicitly linked to a particular type of subscribers. 
For example:
Jurisdiction of Registration: In the case of a Business Entity, the state, province, or locality where the organization has registered its business presence by means of filings by a Principal Individual involved in the business.
Therefore, the EVGL is telling us that the JOR only applies to business entities. And the definition of JOI tells us that it only applies to private organizations and government entities.

Maybe this is just something coming from older versions and has not been updated, but that’s what is written and what I’m bound to apply unless someone tells me that these definitions are outdated or incorrect.

>  
> 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. 

I mostly disagree with this because this is not what is written in the EVGL. What the EVGL say is that we need to include the JOI where operates the registration or incorporation agency, and I can’t see nowhere that the CA must specify the JOI of the verification source that was used for each certificate issuance, or that the relying party can use to find the company details. The information that the CA includes in the certificate must be “the JOI where the agency registered or incorporated that subscriber”, as this the strict interpretation of the EVGL.

As said above, I can understand the rational when you say “Relying parties need to know exactly where to look in the jurisdiction to find the registration”, but even so, we can see that the current approach blatantly fails when using overlapping verification sources, as this produces ambiguous information that make the certificate content either unreliable or irrelevant, and a TLS certificate can’t contain neither unreliable nor irrelevant information.

>  
> 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. 

I agree that the task could be out of scope of the CABF, but I still think that CAs have a responsibility to provide consistent information in the certificates they issue, and for that the EVGL must be respected… and if this is not possible because the rules are unclear or flawed, then the rules should be amended.

In summary I can only maintain my thesis that certificates that include the JOI of a particular registration agency must be consistent across subscribers registered in the same agency. I can’t see any logic on seeing certificates issued by the same CA to the same type of subscriber (or even the same subscriber) and see there different JOI levels for the same registration agency, so something is wrong here, either the practice or the rule.

Besides all the above, I’d still have the open question about the lack of definition in the EVGL about disclosure of QGIS, as it’s only worded in terms of disclosure of registration and incorporation agencies.

>  
> From: Validation <validation-bounces at cabforum.org <mailto: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 <mailto: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 WISeKey <https://url.avanan.click/v2/___http:/www.wisekey.com/___.YXAzOmRpZ2ljZXJ0OmE6bzo5NTgzZGNiMzNhMTNkODlmOTU3MzlkYjcwNGNjZmI0MDo2OjFjMTM6M2Y0NGM0MzcwMTJmNjQ0MjMwZGUwMTkwODc0NDhlYTBmYmJkOGI3MWI0ZTQxYWUwNDRlNzIzNDE3Y2JiNGM0ODpoOkY>
> 
> 
> 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.

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 WISeKey <http://www.wisekey.com/>

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/d2b142a4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3398 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/validation/attachments/20230416/d2b142a4/attachment-0001.p7s>