[cabf_validation] Standardizing jurisdiction information

[Ryan Sleevi]

I believe this also applies to the other OV fields.

I recall one CA (no longer with us) representing the same legal entity
somewhere close to 60 different ways - very clearly tied to who the
validation specialist was and when they did it - in a mix of OV and EV.

On Thu, May 24, 2018 at 4:33 PM, Tim Shirley via Validation <
validation at cabforum.org> wrote:

> 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=06AA9A5A228DDD1D667171B3C2A216
> 8F8811294B9084107B9DFC538B66B72868
>
>
>
> And
>
>
>
> Jurisdiction Locality = LONDON
>
> Jurisdiction State/Province = England
>
> Jurisdiction Country = GB
>
> https://crt.sh/?sha256=A0B24189D56AFFED91CD3839B6B03A
> 9B866022C1AC4C741DB3EF54FC1EAE37A5
>
>
>
> And
>
>
>
> Jurisdiction Locality = LONDON
>
> Jurisdiction Country = GB
>
> https://crt.sh/?sha256=FEF9880CD3466F3CE8D11B8B5E3478
> 66109B02939EDF09337F48C3AD718518AB
>
>
>
> 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=2AF28B1DD551FF423481852F8B7B7F
>    4E065AD1E8A4BCAA38C6F4C97D06F096A5
>    <https://crt.sh/?sha256=2AF28B1DD551FF423481852F8B7B7F4E065AD1E8A4BCAA38C6F4C97D06F096A5>
>    https://crt.sh/?sha256=F801B31CE735A029F609DDBD82F55A
>    4881565111A83770F986E3CBBF6009775F
>    <https://crt.sh/?sha256=F801B31CE735A029F609DDBD82F55A4881565111A83770F986E3CBBF6009775F>
>
>    2. Cases where the same organization is registered in 2 different
>    locales, e.g.
>    https://crt.sh/?sha256=4079456EFF91E573304636B3CE3BDF
>    A9ED24F9C890C48B3A8AE08FE6B27C1A95
>    <https://crt.sh/?sha256=4079456EFF91E573304636B3CE3BDFA9ED24F9C890C48B3A8AE08FE6B27C1A95>
>    https://crt.sh/?sha256=F379C9F7869F52609DADEC77658811
>    7580B6651F184D099EC5FF782EA815913C
>    <https://crt.sh/?sha256=F379C9F7869F52609DADEC776588117580B6651F184D099EC5FF782EA815913C>
>
>    3. Spelling variances of the locality/state
>    https://crt.sh/?sha256=E2240074E0D81D727826671375D874
>    A93A075603C5E14F6B63BA1144AB8EDF43
>    <https://crt.sh/?sha256=E2240074E0D81D727826671375D874A93A075603C5E14F6B63BA1144AB8EDF43>
>    https://crt.sh/?sha256=93B03B402C80E195E40D41CC7D3423
>    70FF9D3B3F801B72870856566F74864B8E
>    <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
>
>
>
> _______________________________________________
> Validation mailing list
> Validation at cabforum.org
> https://cabforum.org/mailman/listinfo/validation
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/validation/attachments/20180524/aca12050/attachment-0001.html>