Comment by solatic | Hacker News Reader

Comment by solatic | Hacker News Reader

The idea behind EV's (to tie domain ownership to real-world legal entities) is sound, it's just that the implementation is poor.

If the EV badge identifies a legal entity plus its country of origin, then how is it supposed to be the CA's fault that there's this leaky abstraction of multiple legal entities with the same name in the same country? If we have a good idea and a poor implementation, then the correct response is to fix the implementation, not throw out the whole idea as fundamentally broken.

Unfortunately, there's also not much that the CAs can do to fix this by themselves. If we want to have a digital representation of a legal entity's identity, the best way to do that is to have a first-class digital identity rather than the hack of a system we have today which attempts to create a poorly supported, non-portable identity on the basis of emailed paperwork and phone calls. Such a first class identity - with private keys controlled by the legal entity, entrusted to the entity when it was first created - will allow clients to verify the identity against the source which actually governs it.

I can understand the privacy concerns surrounding the creation of legal digital personal identities - the creation of a definitive population ledger that goes along with it etc. But for companies? That the US doesn't have such a solution for companies in this day and age is just myopic.

But how would that help? Both Stripes would have a valid first class identity with valid keys. How are clients supposed to then check?

At least it could allow automating retrieving public information of the actual entity by whatever system checks the certification. Now, how to interact with the user to improve cognisance of the entity considered based on the newly available data is another problem.

The certificate itself already automates the retrieval of public information. For example, Paypal's cert includes its full address, which has been verified by the CA:

PayPal, Inc. # Street: 2211 N 1st St # Locality: San Jose # State: California # Postal Code: 95131-2021 # Registered: Delaware, US

And we could include other information if we needed.

Indeed for organisations that have one, the serial number field for the Subject (not to be confused with the serial number of the _certificate_) will be a unique number in some register of companies. In the UK you can mechanically turn those into a URL that gives you the (meagre) Companies House listing, there's no reason the same couldn't be true in the US.

For PayPal this number is 3014267 and it'll be their registration number with the state of Delaware.

The EV rules require a CA to figure out if there is such a number and if so fill it in on the certificate. If there is no number, they're supposed to write something else (a registration date maybe? I don't remember)

(Sometimes a country has some companies that are so crazy old they pre-date the idea of registering companies, or turn out not to exist in their company register because the country created them by passing a law instead of formally registering them, or whatever, and these don't have serial numbers, e.g. I wouldn't be surprised if the Bank of England has no registered company number)

In the current system, the client must query the CA that issued the EV cert for the legal entity data. This presents a number of problems:

a) not all CAs will present enough distinguishing data to the client. Case in point: "Stripe Inc. [US]"

b) No consensus between CAs as to who will issue a cert for a given legal entity. In other words, there is such a thing as a CAA record for DNS and DV certs, but no such thing for EV certs and therefore no verification flow of for a given legal entity -> which CA is permitted to issue -> which domains have been certified for that legal entity

c) No support for more complex identity usecases including name changes, subsidiaries, brand licensing (this FedEx-looking site is run by Acme Local Fulfillment Inc. which has been licensed by FedEx to use the FedEx brand), etc.

Certificate Authorities are not in the business of establishing identity and so they are fundamentally doomed to doing a poor job of verifying identity. Instead of trying to coerce CAs into the identity business because of the inflexible and glacial pace at which government moves, we should be pressuring government to adopt more modern identification practices.

(a) Actually, the CA sends Stripe's actual business registration number in Delaware (4675506). It's the browser who chooses what to present.

(b) Why is this a problem?

(c) Is there any evidence of demand for those usecases? How would you even present them to the users in an understandable way?

"Certificate Authorities are not in the business of establishing identity and so they are fundamentally doomed to doing a poor job of verifying identity."

I don't see how that follows. In fact, I don't see how that's even possible. Whenever you do business with any entity besides the national registry - be it a bank, insurance company, notaries, or even another governmental department - they have to verify your identity. CAs just happens to give you a digital affidavit of the results.

Instead of trying to coerce CAs into the identity business because of the inflexible and glacial pace at which government moves, we should be pressuring government to adopt more modern identification practices.

I disagree; we already have problems with too-big-to-fail CAs; governments are even worse. A CA can be told "follow the CAB Forum rules or get kicked out". But you can't distrust a government when they're the only issuer for the sites of the whole country.

Low-coupling is not just good in software development.

>If we have a good idea and a poor implementation, then the correct response is to fix the implementation, not throw out the whole idea as fundamentally broken.

The point is, nobody wants to fix it, because CAs are still making money.

Reply on news.ycombinator.com