Proposal to enable free and richer EV certificates


#1

Hi,

Here is a proposal for the longer term: what infrastructure can we develop to allow richer, live and free EV++ Certificates to be created. Most of the standards are there, it just requires some initial countries to get together with browser vendors the W3C and IETF to move it along. Does that sound too ambitious? Well, the value added that this procures to those players is not negligible. See:


#2

One relevant data point is that EV certificates do not actually achieve the real world identity verification that people think they do: https://arstechnica.com/information-technology/2017/12/nope-this-isnt-the-https-validated-stripe-website-you-think-it-is/

Automated, free EV would probably still end up an explosion of phishing certificates (just like Let’s Encrypt), though perhaps at a lower rate due to the slightly higher barrier of entry. I would fully expect browsers to make some knee-jerk changes in response to devalue EV.

Personally I think this is all on the browsers. The UI has been bad for a long time and hasn’t really improved in any meaningful way when it comes to understanding what SSL does. The problem is probably correctly identified and well understood, but to me it seems really unlikely that moving the goalposts to EV is the solution.


#3

It’s interesting (and somewhat disturbing) that your post suggests that the reason for the lack of a green padlock in Chrome for co-operating.systems is that it’s using a Let’s Encrypt cert. This isn’t the case; Chrome gives the padlock for plenty of other sites with LE certs (including my own). The issue is rather one of mixed content. That seems like a pretty fundamental thing to get wrong.

And I’m also not convinced that EV certs add much value. See
https://scotthelme.co.uk/are-ev-certificates-worth-the-paper-theyre-written-on/


#4

The page I looked at in Google Chrome Version 68.0.3440.42 (Official Build) beta (64-bit) on OSX - and I think the latest stable Chrome was no different - is https://co-operating.systems/ . I just looked very carefully at the html from that page, and I can’t see any mixed content. All the local URLs are relative and I only have two URLs pointing out at another site.


#5

Marking insecure for a mailto: URI in a form action is probably a bug (or at least a questionable decision by Chrome), but @danb35 is still right that Chrome does show the padlock for Let’s Encrypt DV certificate sites.


#6

…but meanwhile, any number of other sites with Let’s Encrypt certs (including this one) show up with the green padlock. whynopadlock.com identifies the issue as being one of mixed content, specifically the form with a mailto: action. I can’t confirm that’s the reason (and Chrome itself isn’t very informative about what the issue is), but I guess it makes sense. In any event, it obviously is not the Let’s Encrypt cert.


#7

Yep you are right! Who would have thought… I removed the form and I get the green padlock.
I have also removed the whole paragraph in the article that mentioned that, which makes my argument a lot easier to read too. Thanks for the help there.


#8

Very good article thanks. You are right that EV certs as they are deployed now are difficult and very expensive. Large companies don’t care because they have brand recognition, and small companies can’t afford them.
Now my proposal might actually make EV certificates something that letsencrypt could offer, since the verification procedure could be automated and updated very regularly. But it would also allow a much richer set of information to be made available, than what is available in EV certs. This would work because the certificate need only point to the live registry such as companyhouse.gov.uk, which has information about the legal status of the company, if it has paid taxes, how old it is, if it has any legal issues, etc… etc… It would not be up to letsencrypt to do that type of verification and keep all that up to date, but up to the respective country government. The certificate could contain the favicon perhaps to make sure that visual guide is as quickly presented to the user as possible. So I think a lot of the points in that article no longer apply when an institutional web of trust is deployed.


#9

Yep, interesting article. It looks like the UI designers never meet the security ones. Both never meet the Linked Data ones which is the team I am representing. Indeed my PhD thesis in Southampton is trying to bridge these three areas. Actually it’s a typical Apple error described, related to oversimplification. They love a minimalistic UI but don’t seem to have realised that the world is very big, global and not limited to California. That is the reason why one has URLs on the Web!

I don’t see this mistake as showing that nothing can be done in this space to improve the UI. For example I suggest one could have the Favicon verified by the registrar (eg companyhouse.gov.uk) – that could also be done automatically – and that this could then be added to the certificate.


#10

Actually, the full proposal I develop in the article does not need to be deployed for letsencrypt to be able to generate EV certs for UK firms it seems. One would just need companyhouse.gov.uk company page to link back to the server’s domain name, find a way for them to verify this, and letsencrypt could start producing EV certs automatically for UK companies. That seems worth investigating at least. I could try to work out what is needed and find the folks at CompanyHouse to see if they are willing to add the extra fields.


#11

Hi,

EV certs are a good identification… However there are a few issues need to resolve before LE might try to issue EV certificates… (Although LE has already declared that they will not issue any certificate other than DV)

I think let’s encrypt staff could provide you with more details… @schoen

personal ideas, not take it seriously…
First, LE was focused on automation… Personal Identification must need human intervention (so that’s one no go)

Second… If all sites started to use EV certificate then it almost equal to ‘no EV certificate’ since there’s no point…

Thank you


#12

Well, if the domain was a phishing one (https://stripe-support.com) and had an EV certificate for Stripe Inc., it would have had a similar effect on trustworthiness in any browser.

I don’t doubt that EV could be automated for many jurisdictions, even without amending the current Acceptable Methods of Verification.

OID 2.5.4 could easily introduce a new element companyRegistrationUrl and all new EV certificates would be required to include it. Then, the browser could display that information along with the existing subject information (country, company name, etc). That’s the essence of your proposal, right?

I think that’s fine, it’s an incremental improvement to see that info in the browser (even though 99% of users would never even bother to check it. Peter Guttman’s book draft from a few years back Engineering Security talks about this a fair bit, even if you only read the chapter PKI-Me-Harder).

I’m not sure that it would be a meaningful improvement, though. As danb35’s article wrote, users never notice when a certificate is downgraded from EV to DV. What is one to do? Companies start having to publish DNS records that their domains can’t be accessed over DV-certificate domains? How do you publish such a policy for an infinite variation of hypothetical phishing domains? Do we just do away with DV entirely? (no). How does DV co-exist with EV if it’s technologically impossible to make a real-life entity “EV-strict”?

There’s some kind of UI/user education/CA policy/technological equilibrium where the Web PKI actually makes sense, but honestly I think we should be quickly moving away from the notion is “this site is trustworthy” and downgrading the rhetoric to “this connection is not intercepted/this transport is secure”, since that’s all that HTTPS can realistically hope to achieve.


#13

Yes. I have added your name suggestion and OID 2.5.4 link to the article, with a link back to here. I then re-used that name for my HTTP header relation, using the Web Linking RFC for that, which is immediately useable.

Great reference. Thanks. I read that chapter with interest. But his criticism has to do with how UIs are now. Not how they could be. Clearly the browser vendors just have not been thinking seriously about security UI.

I added a paragraph where I suggest that this information just has to be beautiful and in your face.

This would need to be accompanied by a major re-thinking of security UI in browsers. The live information from the website cannot be hidden behind one little icon as it is now, but has to be shown in full before a user reaches a website, perhaps as he waits for the download to complete, especially if he has not visited that website in the recent past. This is essential in cell phones which have so little real estate, that even URLs are mostly invisible. A picture showing where on a globe the company is located, the name of the company, and all the useful legal details would make phishing next to impossible. This view should at all times be easily accessible and perhaps made a bit more visible on pages where the user is entering data into a form.

You can’t rely just on green icons. Rather one has to find a richer visual vocabulary. I think showing by default all the information when available - and none when there is none - as the user first access the site, would teach people that there is some place to look for information such as this.


#14

yes, completely agree on that. Individuals can be tied to instutitons who can do identitfication. But that’s a different topic. :slight_smile:

Not if one improves the security User Interface in the browser, which needs to be very much improved in my opinion in any case. But if we follow this we will have a lot more data to make it worthwhile for people to look at.


#15

I wrote a follow up that took into consideration remarks made here and elsewhere on the internet:


#16

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.