It's pure rent seeking with approximately zero value provided in exchange.

Let's Encrypt demonstrated that the marginal cost of a certificate is close enough to $0 to round down to precisely zero dollars.

To see how deeply rooted this corruption is -- and it is corruption -- ask any major cloud provider like Azure or AWS whether they are willing to provide native ACME protocol integration to enable their customers to request Let's Encrypt certificates for arbitrary DNS-hosted services.

You'll hear nothing back. "No comment" or "We're considering it".

In other words: "We considered it, but then our boss's boss made it very clear to our boss that he was getting a kick-back from DigiCert and to never mention such topics ever again."

...at least, it's pretty hard if your CA is located in a Western country. Which is the big loophole here. The fact that we trust CAs headquartered in arbitrary potentially-unfriendly countries, to make claims about the entire space of domains, is pretty silly. Trusting e.g. the Russian CAs in the trust-store only when they make claims about .ru domains (a.k.a. the X.509 Name Constraint extension), would obviate a lot of the concerns people have about X.509's centrally-curated trust store model.

> [Criterion 2] Physical existence

> To check the organization's physical existence and business presence, the Certificate Authority must verify that the physical address provided by the Applicant is an address where the organization conducts business operations (not a mail drop, P.O. box or an address for an agent of the Organization). This address will be included into the body of the SSL certificate after verification.

That effectively translates to "there should be an address that criminal investigators can be sent to find and detain employees of the company."

> [Criterion 4] Operational existence

> To make sure that an organization is financially active and engaged in business activities, the Certificate Authority must verify that at least one of the following requirements is met:

> The Organization has been in existence for at least three years

> The Organization is registered in the Dun & Bradstreet database or Qualified Government Tax database

> The Organization has an active demand deposit account which can be proved by a bank statement.

That effectively translates to "you can't just make up an LLC and immediately get an EV cert for it, even if you do tell them your house is the headquarters. You'd have to put a good amount of time and effort into simulating a real business. So much that, if this were a spoofing attempt, you'd be noticed as in breach of trademark by the company you're trying to spoof, long before you got away with it."

> Professional Opinion Letter

> If you need to obtain an EV certificate urgently or prefer keeping the company details confidential, it is possible to send a professional opinion letter signed by a Lawyer, Public Notary or Certified Public Accountant. The person who signed the legal opinion or accountant letter should have a valid license within the country where the organization is registered or the country where the organization maintains an office or a physical facility. To expedite the validation process, we highly recommend requesting a Professional Opinion from a person who speaks English so that he or she can confirm the signature during phone verification with a Comodo (now Sectigo CA) validation agent.

And this, finally, translates to "you can mask your identity, but only behind someone who's notoriously signed a Code of Ethics that requires them to surrender your identity to criminal investigators when asked, without needing a subpoena."

https://arstechnica.com/information-technology/2017/12/nope-...

For anyone curious, see RFC 5280 § 4.2.1.10:

   The name constraints extension, which MUST be used only in a CA
   certificate, indicates a name space within which all subject names in
   subsequent certificates in a certification path MUST be located.
   Restrictions apply to the subject distinguished name and apply to
   subject alternative names.  Restrictions apply only when the
   specified name form is present.  If no name of the type is in the
   certificate, the certificate is acceptable.

* https://www.alvestrand.no/objectid/2.5.29.30.html

Client support exists in OpenSSL 1.0.0, Windows 7, Mac OS 10.13.3, iOS 11.2.6. (Android?)

I think one technical 'loophole' is that while NCs apply explicitly to SANs, per the spec they do not apply to the Common Name. Though quickly skimming the RFC, I do not see anything that would prohibit them being applied to the CN. So you can probably do it under the guise of "undefined behaviour".

If any company should operate a CA, it should probably not be random enterprise companies.

For one example: https://wiki.mozilla.org/CA:Visa_Issues

The IETF's PKIX defines how X.509 certificates work for the Internet, because understandably X.509 is for the X.500 system and the Internet is not the X.500 system. PKIX defines the Subject Alternative Name (SAN) which allows the Internet's names (DNS names and IP addresses) to be subjects of X.509 certificates rather than needing the non-existent X.500 directory system for names.

I think you're mostly talking about the Web PKI. But the Web PKI was never "modelled" to work how you've described. At its outset, Netscape (who invented SSL and thus set this ball rolling) wanted pre-existing neutral services rather than they'd run everything and then obviously rival web browsers (including Microsoft's Internet Explorer) would have their own and it's pointless. Several important Certificate Authorities already existed at that time, issuing X.509 certificates in the X.500 system largely to banks, and were happy to take $$$ to issue certificates for this SSL experiment. Initially Netscape basically accepted any company that said they were in this business, and there were no rules (other than those the companies themselves decided on).

But in the modern era the Web PKI is in practice publicly overseen by m.d.s.policy, a policy discussion group of Mozilla. The lack of Name Constraints isn't because of some weird conspiracy, it's simply that Apple didn't support them for many years so if you used Name Constraints then now none of your certificates work on Safari or other Apple products (if Constraints are to work at all they must be marked Mandatory, and if you don't implement a Mandatory feature, you can't be sure if this certificate is valid, so you can't trust it).

For oversight to be effective the sort of delegation you envision is impossible, and accordingly where anything like it did exist the subCAs have moved back to being under physical control of the root CAs. In fact the big problem we had with Symtantec comes down to the lack of effective physical control, with CrossCert able to cause issuance from Symantec's systems yet having no effective oversight.

Also your timeline is badly off in thinking about the IP block allocations. CIDR happened in like 1993, Netscape's SSL doesn't happen until at least 1996. The companies that were issued class A IP blocks before CIDR are mostly smaller and few still exist in the same form, Apple, Comcast and AT&T maybe make sense, but Ford and Prudential Financial not so much. Microsoft are not on that list.