[cabf_validation] Standardizing jurisdiction information

[Tim Shirley]

In looking at / thinking about opportunities for improvement in EV, one of the most prominent things to me is the current lack of standardization in how a legal entity is identified from certificate to certificate.  The idea is that you can take the values from the following fields and use it to unambiguously identify one and only one legal entity to associate with the website:



Jurisdiction Locality

Jurisdiction State/Province

Jurisdiction Country

Business Category

Serial Number



The trouble I see when looking across multiple EV certificates for the same legal entity today is that the contents of those fields often vary from certificate to certificate.  For example, suppose you have a Private Organization incorporated or registered in London.  What should the 3 jurisdiction location fields be set to?  I've seen:



Jurisdiction Locality = LONDON

Jurisdiction State/Province = London

Jurisdiction Country = GB

https://crt.sh/?sha256=06AA9A5A228DDD1D667171B3C2A2168F8811294B9084107B9DFC538B66B72868



And



Jurisdiction Locality = LONDON

Jurisdiction State/Province = England

Jurisdiction Country = GB

https://crt.sh/?sha256=A0B24189D56AFFED91CD3839B6B03A9B866022C1AC4C741DB3EF54FC1EAE37A5



And



Jurisdiction Locality = LONDON

Jurisdiction Country = GB

https://crt.sh/?sha256=FEF9880CD3466F3CE8D11B8B5E347866109B02939EDF09337F48C3AD718518AB



And I'm sure if I kept looking I'd find more variants.  There are a variety of other types of variances I've seen:

1.      Cases where the serial number is left-padded with zeroes in some certificates and not others, e.g.
https://crt.sh/?sha256=2AF28B1DD551FF423481852F8B7B7F4E065AD1E8A4BCAA38C6F4C97D06F096A5
https://crt.sh/?sha256=F801B31CE735A029F609DDBD82F55A4881565111A83770F986E3CBBF6009775F


2.      Cases where the same organization is registered in 2 different locales, e.g.
https://crt.sh/?sha256=4079456EFF91E573304636B3CE3BDFA9ED24F9C890C48B3A8AE08FE6B27C1A95
https://crt.sh/?sha256=F379C9F7869F52609DADEC776588117580B6651F184D099EC5FF782EA815913C


3.      Spelling variances of the locality/state
https://crt.sh/?sha256=E2240074E0D81D727826671375D874A93A075603C5E14F6B63BA1144AB8EDF43
https://crt.sh/?sha256=93B03B402C80E195E40D41CC7D342370FF9D3B3F801B72870856566F74864B8E


4.      Differences in abbreviation in organization name
https://crt.sh/?id=461277165
https://crt.sh/?id=470182592


5.      Transliterations of organization name
https://crt.sh/?id=395749217
https://crt.sh/?id=257827462



None of these variances prevent a person from tracking down the legal entity, but they make it difficult for an automated system to do so.  Making it easier to programmatically link web sites to organizations could help in a variety of applications.  For example, a browser-based filter or proxy server could now interpret live page content as it comes back from the server in the context of the owning organization when scoring how much of a risk the page might pose to the end user before displaying it, providing better real-time fraud prevention capabilities than it could from the page content alone.



I could see 2 broad approaches to fixing this:

1.      Tighter rules around what you can put in these fields.  For example, you might have a table of permitted state/province values per country.  Or you might disallow "foreign" registration info to be used here (assuming there is a single authoritative jurisdiction for all organizations; I'm not familiar enough with this area to know if that's a valid assumption).
2.      A globally-unique identifier of the organization rather than (or in addition to) the location-scoped one we have today.



Any thoughts on the value in attacking this problem?





Tim Shirley

Software Architect

t: +1 412.395.2234



Trustwave | SMART SECURITY ON DEMAND

www.trustwave.com<http://www.trustwave.com/>



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180524/86f22d33/attachment.html>