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
nationwide.
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.
Enjoy
Jakob
--
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
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
