On 14/12/2017 17:51, Peter Bachman wrote:
@Jakob I was referring to the classical namespaces which have evolved since the 1980s. The NSF pilot project was based on a now obsolete version of X.500, Quipu, that world rooted with participating county directories. While I managed that part of the capital D Directory it was in the context of c=US. It was at that point we modified the EDB of the pilot project to include certificates so that the nuclear labs could use low cost Internet mail to collabrate with other organizations to decrease the number of weapons under the negotiated treaties.
So do you mean the "Distinguishe Name" namespace, or not?
During that time the labs went through the process of also proposing and adopting the domain component approach. Still it was possible as an internet user to download a certificate from a part of c=US that was part of that directory tree. Since the certificate is a viable stand alone ASN1 object then it actually does not entirely matter where one obtains the certificate, (but with some caveats as to the original design) which relates to semiotics and the general nature of what is considered authoritative or even useful in the post dot com world. For example, when those of us in the US represent ourselves to people that are not in the US. I can look at the certificate that is pushed to a user (and of course no longer trusted) and say, hmm based on my knowledge of Google, and geography, and business, they are not located in Boca Raton.
What certificate is that? Do you mean the TLS server certificate for www.google.com returned when users access https://www.google.com, and which (as of this moment and seen from my European location has the Distinguished Name: C=US, ST=California, L=Mountain View, O=Google Inc, CN=www.google.com with a validity period of 3 months, issued by an unconstrained Google- operated CA cert issued by one of the soon-to-be-distrusted former Symantec roots). What do you mean by "and of cause no longer trusted"?
I find the EV helpful as a user, but I know it is masking a deeper problem. And I don’t see any of the CA who acknowledge this problem privately as doing the right thing based on a tacit realpolitik that ultimately disadvantages the Internet user with less than optimal security. It’s not that the state chancery errors would replicate into an X.500 environment, on the contrary that is name confusion engineered into DNS to profit from user name confusion. The classic example is whitehouse.com
While this is a known problem, it was originally not engineered to cause confusion but to allow scoping to deal with the inherent ambiguity of existing human chosen names. It was also engineered to clearly and obviously (to all users at the time) distinguish between commercial, educational, telecommunications, military government and civilian government entities.
Registrars offer similar names at a discount bundle price for this reason, it is a business model. At the same time they sell certificates. They blind the ownership in WHOISbecause frankly one gets horribly spammed when one uses WHOIS the way it was intended in the original DDN-NIC version of the 1980s.
As someone who has not blinded our addresses in whois, I strongly resent such blinding and see it as a sign of likely dishonesty of the domain holder. I also find that the resulting amount of e-mail spam (after minimal filtering) is actually quite tolerable. The amount of spam calls to our front desk phone number is worse, but that number is widely published elsewhere.
So the Internet needs to have a viable trust framework and one already exists under c=US, using X.500. which feeds the various trust frameworks that don’t entirely trust the Internet.
Can you point directly to where that framework actually exists (like a URL or an institution that currently operates and maintains it)?
CT is one of those technologies that benefits the Internet directly, but the business model is based on these separate organizations which the CA interact with, the selling proposition to them is that the BR are BS. You need my dear customer a trust framework that uniquely represents you as a member of the Carpenters Union so your unique woodworking skills are fairly representated. As opposed to anyone who can set up shop as Stripe Carpenters with a business registration.
So far, CT has mostly been used as an audit and enforcement mechanism for detecting and policing BR violations. So its selling proposition is clearly not "the BR are BS". CT has nothing to do with the existence or non-existence of widely trusted mechanisms for issuing certificates that indicate skills, professional organization membership or other such non-geographic hierarchical status. Such a structure would also not be a good fit for the Distinguished Name structure that typically resembles a postal address.
That allows for the enterprise certificates and directories as a market, the government and military who to some extent use the commercial CA, but also do not, and thus gain the advantages of cross certification using X.500 at the Federal Bridge between these major siloed trust frameworks.
????
The DN is inherently unique. The Internet enterprise OID is something else. If geography has anything to do with this, then it’s possible to extend c=US to have semantic meaning.
Actually, the Distinguished Name is not inherently unique unless backed by a database or directory enforcing this. The "Stripe" case that started this thread very much involved the absence of such a database for US government recognized company names. OIDs, including Internet enterprise OIDs are inherently unique based on a strict hierarchical assignment system.
According to the last extant analysis done. The US government can’t solely be c=US, that’s a common namespace confusion.
Of cause. C=US refers to the entirety of the US nation, of which the government is just one major part.
They are at an Organization level. However there are two OID paths in that regard.
What OID paths? 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
