On 12/12/2017 16:57, Peter Bachman wrote:
I think this is fundamentally an issue of the history of the DNS and X.500
architecture. Combined with social factors since 1996 when the original NSF
Directory and DNS grant money ran out, and domains (which had been free) became
this wild west name space, which has reached some predictable level of
insecurity. Inevitably the classic solutions are brought out and rejected. I
think the rapid growth of the Internet has been achieved in terms of IP over
everything, but security is always going to be a work in progress.
People who understand X.509 versions understand that the original version was
highly integrated with the Directory, which provides its own level of
assurance. It was also stifling. However we are seeing a renewed interest in
directory variants around the issue of lowering US healthcare processing
overhead. Using the Internet has been on the agenda since 2004.
There’s a long thread here dating back to the 1980’s regarding naming,
resulting in the fields that are eventually defined in RFC 5280.
The ANSI registration component is permanent and perpetual.
If you are referring to the OID namespace (as opposed to the
"distinguished name" namespace), then both the IETF, Mozilla
and most other relevant organizations have their own branches
in that tree. Many of those are subtrees under the "enterprise
ID" suballocation from IANA.
Of cause, the OID tree is rooted at ISO and ITU, not the US-specific
ANSI. Also, it is generally used to identify technical elements (such
as fields and data types) rather than organizations and businesses.
If you are referring to the "distinguished name" namespace to which
X.509 certificates are actually issued, 3 competing and overlapping
branches exist:
1. The traditional (telephone) directory namespace organized by
geographical/postal address and generally unpopulated due to not
being set up by most national telephone companies.
2. An ad-hoc equivalent of the traditional directory namespace, not
explicitly stored anywhere but instead filled out based on available
traditional information sources such as the postal addresses found in
various public records. This is what most public X.509 certificates
are currently issued to, with a slight misuse of the "common name" as
a "DNS address" field due to early deployments by Netscape (now
Mozilla). The EV program under discussion here is a set of minimum
requirements for certificate issuers to verify the applicants
directory name details before signing certificates containing those.
3. An X.500-style restatement of the DNS namespace, using distinguished
name component of the form "DC=label". This is used in the internal
company X.500 directories in companies that use Microsoft's directory
management software, but appears to be older, an early variant can be
found in RFC1274 though I am not sure if the DC (DomainComponent)
definition is still the same and if it still uses the OID
ITU(?)-data(9)-pss(2342)-ucl(19200300)-pilot(100)-
pilotAttributeType(1)-domainComponent(25)
(Not sure if this syntax is entirely correct)
4. A "dummy" branch where members contain only DNS names in commonName
and non-X.500 extensions, country name (where known or wrong) and some
metadata about certificate issuance. This branch of the X.500
namespace is used for so called DV certificates, where only a
mechanical check of DNS name ownership is done. The CAB/F "Basic
requirements" and Mozilla policy provides minimum standards for this
mechanical checking.
Like most elements of the Internet that remain insecure, it’s a matter of
ubiquitous access (domains are cheap, it costs more money to validate a
business or organization, so the less secure solution is adopted) or other
solutions like pinning are tried.
I would be open to partnering with Mozilla and doing this using X.500, but the
ANSI name and OID fee is high. Which is the case also with NIST LOA 3
certificates. I’m certainly open to any ideas to make this work. Right now
there is a governance gap of a organization equivalent to ICANN that is
addressed by various industry organizations that do well known certificate
cross certification at the Federal Bridge and European trust anchors.
The overall problem addressed by WebPKI certificates is verifying that
the server end of a network connection is:
- The actual user-requested DNS name.
AND (optional):
- A specific real-world entity such as a business, government entity,
NGO, inter-governmental organizations etc., whose identity can be
presented to the human user to let them know who they are communicating
with.
The problem that started this thread was that the current WebPKI system
provides no workaround for the real-world problem that many of the
worlds jurisdictions allows the creation of actual legal businesses etc.
with misleading names, and the fact that once a government entity has
allowed such a misleadingly named business to officially exist in the
real world, it might obtain WebPKI certificates bearing that confusing
but legally authorized name. If the relevant government operated an
X.500 directory of legally existing businesses, the confusing entries
would exist in that X.500 directory.
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
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
