
The browsers are probably running the TLS show now - gdwatson
https://utcc.utoronto.ca/~cks/space/blog/web/BrowsersRunningTLSNow
======
walrus01
Rather than browsers arbitrarily only trusting certain lengths of certs, of
much greater concern to me is the number of root CAs trusted by every major
browser, some of which are companies under the control of authoritarian states
(Turkey, China).

Go take a look at how many CAs your browser trusts, and tell me with a
straight face that you absolutely trust every one of those CAs to always do
the right thing.

Certificate issuance transparency helps, but doesn't get rid of the
fundamental issue.

~~~
Santosh83
On the one hand we argue the Internet should be global and not get Balkanized
and on the other hand we arbitrarily select certain countries to place lesser
or higher trust in. Someone in China could legitimately have a similar low
level of trust for US root certs and he/she would not be far wrong given that
NSLs can gag companies into complying with arbitrary dictums that no one ever
knows about.

~~~
chongli
The original hacker dream of the internet was that it would break down borders
and open up the free flow of information. Now that non-hacker types
(politicians and bureaucrats, mainly) have had access for a few decades,
they've realized how powerful a tool it is for empowering their authoritarian
impulses.

Call me cynical but I think it's only a matter of time before the internet
becomes totally Balkanized. Heck, it's almost there right now.

~~~
ferzul
we have ports for everything else, internet ports will come. it'll suck for
me.

------
tptacek
Thank Christ. The browsers have been far, far better stewards of the Web PKI
than the CA/B Forum (at large) has been, and, in the main, the Web PKI exists
to support browser security. That the major browser vendors are getting more
muscular about their demands is a major shift: antitrust was a real concern
that prevented a lot of important Web PKI stuff from happening sooner. But
with Google and Mozilla breaking the largest CAs over documented misissuance,
it's possible that concern has finally gone by the wayside.

------
Spivak
I feel like this is a fairly narrow view of the situation. In theory the CA
"System" ought to be much bigger than just web traffic since a globally
distributed hierarchical database of certs is neat and could be used for all
sorts of stuff.

The fact that browsers have so much say in how the CAs operate that database
makes me think that the public CA system is actually a wildly successful
failure. If the public CA system has no other use than to allow someone to
securely connect to one of a handful of web browsers then why all the fanfare
over just having letting the companies stewarding the browsers run the show
entirely?

~~~
tptacek
People say this a lot. But where are the examples of all the "stuff" that
would benefit by being linked into a single global PKI? Many of the most
important public key crypto tools people actually use --- Signal, SSH and SSH
CAs, U2F and WebAuthn, OAuth2 --- have little or no PKI at all.

~~~
Avamander
> But where are the examples of all the "stuff" that would benefit by being
> linked into a single global PKI?

Estonia's national system and its e-services are a local example of a single
central PKI. Provided services and systems seem to be far ahead of basically
all other countries.

Identity theft, identification, authentication, signing etc. have been solved
for nearly two decades now and I have to say the way the rest of the world
does stuff looks stone-age to me.

For example I __loathe __how I 've been asked to do identity verification by
foreign companies "send us a picture of your ID", WTF. Sentences like "Use SMS
2FA to protect your account", "e-mail us the bill" and "come to our office to
sign {x}" make me shudder, it's absolutely dogs __*.

~~~
wahern
The anti-PKI crowd are getting waayyyyy ahead of themselves. Pretty much any
large deployment of public-key cryptographic needs some sort of PKI. Any
framework where there's a third-party authority that signs keys requires some
sort of PKI, directly, indirectly, or both. And there's almost always such a
third-party because otherwise public-key cryptography is barely just a step
ahead of shared secrets. This is especially true when you have distinct
vendors, but I can guarantee you that even Signal has an internal PKI
framework, independent of the Android PKI framework that it also implicitly
relies upon.

Someone else thread mentioned S/MIME. S/MIME might be a failure, but S/MIME is
a thin wrapper around CMS (Content Messaging Syntax), which is widely deployed
standard for signing, authenticating, and encrypting content. It's based on
the same ASN.1 standards as PKIX. And like PKIX, the root authorities are
whatever you want them to be; the standards just provide the syntax and
semantics for building the PKI and providing interoperable messaging.

Correct me if I'm wrong, but AFAIU CMS is the basis for various European
digital identity systems. See, e.g.,
[https://en.wikipedia.org/wiki/CAdES_(computing)](https://en.wikipedia.org/wiki/CAdES_\(computing\))

~~~
tptacek
You tried the same rhetorical sleight of hand in a different thread a week
ago; what you're doing is claiming that any use of asymmetric cryptography is
by definition a form of PKI, when what we're talking about --- top-down tree-
structured global PKI --- is clearly different from what they're doing.

Your point about S/MIME and CMS kind of makes my overall point for me. Sure. A
global PKI is super useful for making things like CMS happen.

~~~
wahern
_You 're_ talking about _global_ PKI. But the "public" in PKI doesn't imply
global any more than the public in public-key cryptography does.

What PKI does usually imply is some sort of top-down tree of trust and
mechanisms and policy for managing and verifying that tree. But the roots of
that tree of trust don't have to be global, and with the exception of Web PKI
aren't.

You're creating the straw man. You keep saying that new protocols don't need
PKI. Well, if we accept your criteria for what PKI means, and considering that
the only example that meets your criteria, past, present, or future, is Web
PKI, then what exactly is the point of your argument?

If you have a beef against PKIX, CMS, X.509, ASN.1 etc--i.e. the _mechanisms_
\--then just say so. There's a ton of reasonable criticism to be made there.
But those things are not equivalent to "PKI". There are plenty of PKI systems
out there that make use of alternative mechanisms, though mostly proprietary
and hidden as interoperability usually demands making use of pre-existing
standards. But, to reiterate, using those standards to build a PKI system
absolutely does not require relying on the same global roots of trusts.
Nothing in those standards even identifies such a root or the shape of the
tree at all.

~~~
tptacek
No. _We 're_ talking talking about global PKI. See: rest of thread. You're the
one who's departed from the topic.

------
nullc
Why is this an improvement? Has there been a rash of stolen certificates or
domain name ownership changes? Is having a third party with a cert for a
domain you're using for 12 months acceptable in a way that 2 years isn't?

It would be nicer if certs could be issued with long lives but required a
stapled revalidation with a short time span (daily? weekly?), which would be
automatically issued at any time requested unless the certificate was revoked.

~~~
hamandcheese
How does that help vs simply having short lived certificates?

~~~
nullc
(re-)Validation costs. In theory, if it was just a "not revoked" signature,
anyone could obtain it. No access to thorny private keys needed, etc.

------
falcolas
This is an unexpected (from someone outside the cert industry) development. I
know for sure it will have some impact on servers I manage, since we typically
purchase 2 year certs, and issue 5 year certs internally.

It's also been shown recently that not all companies are great at managing
their certs, with notable shutdowns associated with expired certificates.
Increasing the frequency of updating certs should be a good thing, but in
practice I'm afraid that it will remain a manual project for some time to
come.

~~~
Avamander
I don't think it's unexpected. Browsers are _the_ lifeblood of CAs.

Unless CAs insert themselves more into the process of code signing, S/MIME,
GPG or something like that. They will remain under the heavy influence of
browsers.

~~~
falcolas
The move to 1 year is what was unexpected to me. Browsers taking over the
rules around CAs, I agree that it's a natural expansion.

~~~
Avamander
Browsers did the same thing with Certificate Transparency earlier, unnoticed
to many.

~~~
tialaramex
And this is like that in an important way, for now.

Chrome and Safari both have browsers which implement a check such that you
need to present enough "qualified" SCTs or the certificate is treated as
invalid.

The easiest way to pass that check (for certificates you're going to sell or
give to webmasters with no clue) is to log a pre-certificate with Google, and
with at least one (preferably two) other logs that Apple and Google agree are
trustworthy - then bake the SCTs you get back from those logs into the X.509
certificate you're issuing.

But these are not Trust Store policy requirements. If you in fact choose to
issue (for a number of reasons some CAs do) without logging that's still
permitted, the certificates just won't be trusted in Chrome or Safari. You
obviously won't get far selling certificates that don't work out of the box in
Chrome or Safari to the average punter, but not every customer is the average
punter.

Apple's _declared_ intention is that Safari will not trust long-lived
certificates. But as far as I've seen it is _not_ specified that they would
consider a CA which chooses to issue such certificates to violate Apple trust
store policy and pursue any sanction or demand revocation. The certificate
just doesn't work in Safari.

Now, today Mozilla's Firefox is in a different situation from Safari and
Chrome as I mentioned elsewhere. Firefox doesn't do a lot of technical
enforcement. Mozilla works hard (and in public where we can all see) on policy
decisions, but most of them are not enforced in its flagship browser product.
Mozilla champions CT logging for example, but a brand new certificate
presented with no SCTs works fine in Firefox even though it'd be rejected by
Safari and Chrome. Today Firefox doesn't require 825 day lifetime limits, even
though those are the limits set in policy, and so following Apple's suggestion
wouldn't actually be easy for them, there isn't a line of code (as there is in
Chrome for example) that multiples 825 * 86400 = maximum lifetime in seconds,
which can be adjusted to say 398 or some other number of days instead of 825.

------
quotemstr
And the browsers, in turn, are controlled by a few big tech companies. Is it a
good idea to give those companies control over the trust architecture of the
internet? What happens if you get on tech's persona non grata list? Do you not
get to use the PKI?

~~~
tialaramex
You'd need to ask Microsoft about that, theirs is (as far as I know) the only
Trust Store which demands they get unilateral override for revocation
decisions.

That is, if Mozilla, or Apple, or Google reach out to Let's Encrypt and say
"killtrump.example is not acceptable, revoke their certificate" Let's Encrypt
says "No" and nothing happens. But if Microsoft does so, Let's Encrypt can say
"Please reconsider this seems like a bad idea" and then Microsoft can say
"We've thought about it, revoke" and the choice is only whether Let's Encrypt
wants to remain trusted in Microsoft's products.

Nobody else has a rule like that, and it isn't a new rule, it's a published
part of Microsoft's policy. Microsoft says they use it only to protect
Microsoft's customers from phishing and similar attacks. Perhaps that's even
true.

------
rossdavidh
It is difficult to find a group of companies less trusted to do the right
thing than the major browsers (Apple, Google, Microsoft). However, the CAs
qualifies, ironically perhaps, as less trusted.

------
tylerl
At no point have the browsers ever _not_ been running the whole TLS show. The
CAB forum is a useful construct, but its usefulness has a specific place.

Imagine a weird little town with 6 people who buy all the groceries and a 60
grocery stores. The stores get together periodically and meet with the 6
shoppers to talk about what the stores should stock. Maybe they even vote.

That be a useful set of meetings.

But ultimately those 6 customers are going to buy whatever the hell they want
to buy, regardless of how the votes went.

------
prepend
Does certificate length really matter? It seems like other factors related to
certificates are much more important than the ability for a cert to be stolen,
reused, and not revoked.

~~~
will4274
Cert revocation for the web is broken, which is why there's been so much
emphasis on lifetime. Revocation checks are a privacy leak and reliability
degradation and DoS vector, unless you use something like OCSP stapling, which
fairly few sites do.

~~~
dochtman
Mozilla is starting to do CRLite, which should be an improvement here:

[https://blog.mozilla.org/security/2020/01/09/crlite-
part-1-a...](https://blog.mozilla.org/security/2020/01/09/crlite-part-1-all-
web-pki-revocations-compressed/)

