
Digicert Withdraws from the CA Security Council - dokov
https://www.digicert.com/blog/notice-of-withdrawal-from-the-ca-security-council/
======
geofft
Note that this is not the CA/Browser Forum, the usual industry association you
hear about. The CA Security Council is a group of a small number of old-guard
CAs, which has been notable recently for pushing a distinction between
(automatic) domain validation, organizational validation, and Extended
Validation, mostly as a response to Let's Encrypt. The "London Protocol"
appears to be a proposal for formalizing the distinction between DV and OV +
EV: [https://casecurity.org/2018/06/27/the-london-
protocol/](https://casecurity.org/2018/06/27/the-london-protocol/)

If you look at this previous paper they (Entrust + Comodo) published, they're
proposing that OV and EV certificates get padlocks and DV ones don't:
[https://casecurity.org/wp-
content/uploads/2017/09/Incidence-...](https://casecurity.org/wp-
content/uploads/2017/09/Incidence-of-Phishing-Among-DV-OV-and-EV-
Websites-9-13-2017-short-ve....pdf) Or, in other words, you can't get a
padlock from Let's Encrypt and you'll have to pay them for a padlock.

Compare with Google's plan at [https://blog.chromium.org/2018/05/evolving-
chromes-security-...](https://blog.chromium.org/2018/05/evolving-chromes-
security-indicators.html) which just drops the padlock for _everyone_ , treats
plaintext HTTP as affirmatively insecure, and stops pretending that paying
money to a CA means that you're a morally upright website.

A CA leaving the CASC seems like a good thing for the world.

~~~
threeseed
It's an interesting question: is there value to certificate identity
verification ?

Apple's App Store for example demands that companies wanting to publish apps
have to undergo a verification process using a DUNS number. And this has been
useful for example in resolving trademark and DMCA disputes. But not really
sure if it's improved security in any way.

~~~
geofft
Apple's case is a little different because it lets you publish native code on
the phone. (You can argue that websites effectively also publish code, but the
web sandbox is probably quite a bit stronger than the iOS one.)

I don't think there's much advantage in knowing that you're _some_ registered
organization. It's pretty easy to register an organization - see e.g.
[https://stripe.ian.sh](https://stripe.ian.sh) , to which the CASC responded
by proposing the rule "Applicants that have been in existence for less than 18
months are not eligible for EV certificates," as well as a requirement that
the CA inspect your tax returns to make sure you're a bona-fide business. This
is basically a losing game (losing for the CAs, because it won't work, and
losing for the world, because startups can't get EV certificates and everyone
else loses their privacy), hence my comment about validating that you're a
morally upright website. It's the evil bit, except as a TLS extension.

One thing that does have value, though, is making sure a website is the
_right_ website. It's perfectly fine for
[https://stripe.ian.sh](https://stripe.ian.sh) to have a cert as long as they
don't get my [https://stripe.com](https://stripe.com) credentials or cookies.
On the cookie side, the browsers already solve this with the same-origin
policy, so the hard part is just making sure that you don't enter usable login
credentials on the wrong website (i.e., preventing phishing, which is the
stated goal of CASC). There are pretty good solutions for this like FIDO/FIDO2
- in the future I'd like to see places like banks either giving you U2F
security keys or letting you bring your security key in when you enroll for an
account and activate it on their machine, because the FIDO protocol lets the
security key participate in the same-origin policy. If I've enrolled my key
with bankofamerica.com, and my login requires using a security key, I _can 't_
divulge usable credentials to bankofamerica-secure-login-trust-me.com.

Relatedly, the same-origin policy doesn't (and can't) distinguish between the
type of HTTPS you have or whether there's a verified organization name on the
cert. It treats any HTTPS for the same domain as the same origin. So the
browser makers have been pushing back against meaningful distinctions between
DV, OV, and EV (and also against EV even having any costmetic distinctions),
which is completely at odds with the CASC's strategy. Sucks for the CASC
because it means a $0 Let's Encrypt certificate is as meaningful as a $300+ EV
certificate, but I think the browser makers are right, here.

~~~
snowwrestler
Same-origin policy does not help you on first visit, and trust on first visit
is really the hard problem that PKI was invented to solve.

If you can count on a prior relationship in encryption, then you don't even
really need PKI. Just mutually decide on an encryption key and then use that
to encrypt/decrypt your traffic.

Not every website is Twitter or Facebook or Google or a major bank, where the
vast majority of visits are repeat visitors. I run dozens of websites, and
every single one has more than 50% new visitors, year in and year out. That is
representative of the _vast_ majority of websites out there.

Browser makers have dramatically shifted their security focus toward repeat
visitors. Two-factor authentication, same-origin policy, HSTS, and other new
security features are only useful for repeat visitors.

EV certificate notices (the "green banner" in the address bar) are one of the
very few browser features that attempt to help first-time site visitors. Now,
obviously EV certs have problems as you cite with Stripe... but instead of
trying to solve this problem, browser makers are simply _copping out_ and
falling back on a posture that HTTPS just means encrypted over the wire, not
identity. Essentially: establishing security is the user's problem. Once it's
established, then we've got all sorts of tools to maintain it.

This is a mistake. It does not help most websites, and it privileges incumbent
services (which have lots of repeat visitors) over new websites (who are
trying to win new customers).

CAs and browser makers _must_ continue to attack the problem of trust on first
visit. It's not an easy problem but it is the essence of the promise of the
web. Visitors should be able to load a new site and know if it is trustworthy,
just like people trust that they can physically walk into a new store and not
get robbed.

~~~
voidmain
If you want to know if a site is _trustworthy_ , you want a certificate from
their insurance company, not their CA. Someone who is promising to pay you
real money if the site contains malware or a scam or whatever. Unfortunately
this sort of insurance would probably be more, not less, expensive than EV
certs.

~~~
snowwrestler
That type of insurance is often called cyber insurance, and is pretty common
among businesses. I work for a nonprofit--not even a tech company--and we
carry cyber insurance and require all our technology vendors to carry it too.

Personally, I would not be opposed to CAs requiring proof of cyber insurance
in order to issue an EV cert.

~~~
voidmain
"Cyber insurance" may reimburse the site operator for the liability they have
to you for (say) being infested with malware. And that model seems to work OK
for car accidents. But I think that only helps you (the site visitor) if you
already have a practical ability to sue the site operator (particularly
difficult if the site operator is on the other side of the globe, in a
jurisdiction you know nothing about). What I'm proposing is that the insurance
company offers to accept direct liability to site visitors, with well defined
liquidated damages and arbitration processes so that it actually means
something to the user.

If someone is offering that today, they aren't marketing it well. And again,
actually signing the certificates would be a negligible part of the business
(or the cost).

Actually, if I were in the insurance business I'd actually think about pushing
this direction. If you could get the browsers to sign up for giving it special
treatment it would probably greatly increase the size of the market. (Right
now operators seem to mostly just escape significant liability for
compromises)

------
JoshTriplett
I'd be curious the real reasons for this, because the reasons listed in this
press release sound like marketing-speak.

~~~
vbezhenar
letsencrypt destroying their business model, they are trying to find new
sources of income.

~~~
tialaramex
I didn't look in the last few months, but most definitely when I did last look
the reality is that Let's Encrypt and the strongly related "HTTPS Everywhere"
movement actually drove growth for the _entire CA industry_

This is undoubtedly at least in part due to a halo effect. If Alice and Bob
have $0 Let's Encrypt certs for their blogs about, respectively, an obscure
species of tree frog and restoring muscle cars, when Carol asks them if her
new business "needs" an SSL certificate they are more likely to say "Yes"
rather than "Not really" or "I don't know what that is". Even if most Carols
use Let's Encrypt, any who don't are new customers for a commercial CA.

~~~
vbezhenar
I think that a lot of small customers moved from commercial CAs to
letsencrypt. I don't even know a single reason not to use letsencrypt now.
Sure, there will be new customers, but I'm not sure about old customers and
it'll be worse as existing customers slowly would learn about free letsencrypt
and migrate to it.

------
michaelbuckbee
I have mixed feelings about all of this. The big philosophical divide is
really around what you think a cert/https should mean.

The one side (I'm summarizing here) says that HTTPS only means that the data
transferred over the wire is secure and has nothing to do with authenticating
that you're actually talking to the correct website. And that's correct, there
are all sorts of MITM attacks, etc. that could be done and people shouldn't
automatically trust that seeing a green lock means it's safe to put their
password into a website. And that's correct.

The other side says: nothing is 100% secure and security is all about defense
in depth and these EV certs can be really helpful. Consider the Washington
Post:

[https://www.washingtonpost.com/](https://www.washingtonpost.com/)

There is a whole cottage industry of unscrupulous advertisers who make their
living off of scraping the look and feel of websites like the WashingtonPost,
setting up a URL like washingtonpostnews.com and then making up a fake story
about how the Rock was arrested because he had some special muscle growing
formula on him that oh look they have a link to buy for only $15/mo.

It's quite unlikely that an EV cert would be issued for washingtonpostnews.com
and it doesn't seem crazy to think that there is some value in having the EV
cert on the proper www.washingtonpost.com website.

They'll also point out that even DV cert issuance pre LetsEncrypt was a mixed
bag of good and bad. Some CA's wouldn't issue you a cert if it had certain
habitually abused trademark names, etc. in it. You'd have to do more than just
have an email address or a DNS entry for it. This is for terms like BMW,
Tesla, Facebook, etc. and this practice legitimately tripped up (but likely
didn't stop) a metric ton of phishing sites.

I think LetsEncrypt is awesome and makes a ton of sense and probably has made
the internet safer in general. But the general response to things like
LetsEncrypt issuing upwards of 15,000 different certs for domains containing
"paypal" [1] is that you should rely upon sending your browsing information to
Google, Microsoft, etc. so that they can tell you "Warning this is a possible
Phishing Site" [2] which worryingly seems like we've then replaced multiple
CAs (which we thought were too centralized) with an even fewer number of
browser vendors (which are even more centralized).

1 -
[https://www.bleepingcomputer.com/news/security/14-766-lets-e...](https://www.bleepingcomputer.com/news/security/14-766-lets-
encrypt-ssl-certificates-issued-to-paypal-phishing-sites/)

2 -
[https://www.google.com/safebrowsing/static/faq.html](https://www.google.com/safebrowsing/static/faq.html)

~~~
ubernostrum
As Troy Hunt has been at pains to point out, some of the largest, most
important and most spoofed/phished sites on the internet use only DV certs.

Google, Amazon, Facebook, and eBay are all DV. If they don't see value in
EV/OV, then who on earth is it meant for?

~~~
nailer
OTOH: your bank, Apple, GitHub, npm, most fintech companies do.

And yes your bank account is a higher value target than your gmail.

~~~
tialaramex
It's all very well that my bank does, but it displays "National Savings and
Invest..." which isn't its full name and would also be shown for any number of
businesses with the same start to their name.

My mother's bank says "Lloyd's Banking Group PLC" which isn't its name, you'd
have to know that it's owned by another group of banks to decode that.

Another of my accounts says "first direct (HSBC Bank plc)". It so happens I
know that First Direct is owned by HSBC, but if I didn't shouldn't that
further concern me?

This all ends up as extra cognitive load for humans, and it barely contributes
to helping with the problem, because this information is only (can only be)
displayed after all the backend stuff has finished happening, so it's too late
to tell me that wasn't really my bank after I tell them my password...

~~~
nailer
It's a seperate topic, but yes, there's definitely a need to improve how names
map to human understanding. Most people know 'Coke' or 'Coca Coca' than 'The
Coca Cola Company' or 'CCA Amatil' or cocacola.com.im. There's discussion
(mainly led by DigiCert) now about making EV use trademarks.

------
zizek23
The certificate system is broken. Technical people should not be promoting
centralization, raising barriers to publishing and empowering middle men. That
is not a technical solution, but behavior that favours business and vested
interests.

There is now a clear pattern of attempts to raise barriers and cede more
control to actors in the middle.

First it was de-legitimizing http, now its standard certs, then it will be 3
years. What's stopping this degenerating into an elaborate 'approval process'
from a central authority in a few years which you pay dearly for, all in the
name of security?

This kind of control gives some the power and fig leaf of any 'arbritary
process' to delegitimize and silence others.

