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

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

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.


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

Reply via email to