2021-01-03
TLS Certificate Authority root certificates and their dates
One response to the idea that Certificate Authority root certificates in your system's trust store should have their dates ignored (which is done in practice by some versions of Android and which you might put forward as a philosophical argument) is to ask why CA root certificates even have dates in that case. Or to put it another way, if CA root certificates have dates, shouldn't we respect them?
I think there are two levels of answers about why CA root certificates have dates. The first level is that 'not before' and 'not after' times are required in TLS certificates, and there is no special exemption for CA root certificates (this has been required since at least RFC 3280). As a practical matter, using well-formed and not to badly out of range times is probably required because doing otherwise risks having certificate parsing libraries rejecting your root certificate.
The second level is that more or less from the start of SSL I believe there was at least a social expectation that Certificate Authority root certificates would have 'reasonable' expiry dates. People could have generated root certificates that expired in 2099 (or 2199), but they didn't; instead they picked much closer expiry times. Some of this was probably driven by general cryptographic principles of limited lifetimes being good. Back in the early days of SSL (and it was SSL then), this didn't seem as dangerous as it might to us today because it was often a lot easier to get new root certificates into browser and operating system trust stores.
(Some of it may have been driven by fears of running into the Unix year 2038 problem if you had certificate expiry times that were past that point. Some modern CA root certificates carefully come very close to but not past this time, such as this Comodo root certificate, which has an end time that is slightly over three hours before the critical Unix timestamp. On the other hand, Amazon has CA 2, CA 3, and CA 4 that expire in 2040. And HongKong Post Root CA 3 expires in 2042.)
Given that root certificates have to have dates and even early ones likely faced various pressure to not make their end date too far into the future, the end dates of root certificates don't necessarily reflect the point at which one should end trust in a root certificate. Since there isn't general agreement about this, there probably wouldn't be enough support to introduce a special far off date to signal 'trust forever' and then explicitly treat all other dates as real cutoff dates.
(Mozilla may have a policy on the maximum validity of root certificates they'll include, but if so I can't find it. Their current report of CA root certificates in Firefox (see also) currently seems to have nothing after 2046.)
The modern web and (alleged) software stagnation in the past few decades
I was recently reading The Great Software Stagnation (via), which puts forward a simple thesis:
Software is eating the world. But progress in software technology itself largely stalled around 1996. [...]
I have a number of reactions to that, but one of them is that one specific yet obvious area of software technology has progressed hugely in the last 24 years, or even the last ten, and that is the 'application' web (which these days is not just Javascript but also CSS and HTML features that allow interactivity, animation, and so on). What you can do with the web today is quietly astounding, not just for the web but at all.
Back in 1996, software technology might have allowed you to build a global, high detail map as an application that was delivered on CD-ROM (not DVD, not in 1996). But you definitely wouldn't have been able to have that map on almost any device, and have it updated frequently, and have high resolution satellite views of much of the west included (and probably not all of the map details, either). Nor would you probably have been able to include interactive, highly responsive route planning, including for bicycling.
(If you consider the backend systems for this web application as well, much of the software technology necessary to operate them likely postdates 1996 as well.)
Maps are everyone's go-to example of web application technology, but I have another one that is much closer to home for me. Here in 2021, I can easily deliver to my co-workers (in a very small organization) a whole set of custom monitoring dashboards with custom graphs, information tables, and other visualization displays that I can update frequently and that are available on basically any computer you care to name (this would be our Grafana dashboards). There's an entire ecology of software technologies that enables all of this, and almost none of them existed in 1996 in any meaningful form.
(I will argue that not even Javascript existed in 1996 in meaningful form; the Javascript of 1996 is significantly different from the Javascript of these past five years or so.)
Could you have theoretically done this in 1996? Yes. Could I have practically done this in 1996? No. The web's software technologies have made it possible to build this and the sea change in the viability of the web itself has made it possible to deliver this (including ongoing updates to how the dashboards work, adding new dashboards, and so on).
(There were monitoring dashboards in 1996, and I know the university had some of them, watched by operators in our central machine room. But they were not delivered over the web, and I'm pretty certain they were very expensive enterprise software and much more time consuming (and expensive) to customize and operate than our setup.)
These are not the only web applications that more or less couldn't have existed in 1996 in any form. Even some ostensibly relatively plain websites could not have existed with 1996 software technology even if you gave them 2020 hardware technology, because of their sheer scope. People have been talking to each other over the Internet for a long time (as I'm very familiar with), but Twitter's global scale and activity create a whole new set of problems that require post-1996 software technology to deal with, often in areas that are genuinely new.
(Much of this software technology is less obviously sexy than new languages with new models of programming. But it's also quite sophisticated and represents real progress in the state of the art in things like distributed consensus and large scale data stores.)
In looking at all of this, I'm strongly reminded of another article I read recently, Dan Luu's Against essential and accidental complexity. This basically takes the other side of the 'things have stalled' argument by walking through some drastic changes in programmer productivity over the past several decades. Dan Luu's starting point is roughly 1986 for reasons covered in the article, but many of the changes Luu points to are from after 1996.
PS: Another web-related area that software technology has made huge strides in since 1996 is almost everything related to cryptography. My strong impression is that much of this progress has been driven by the existence of the HTTPS web, due to the web being where most cryptography is used (or more broadly, TLS, which is driven by the web even if it's used beyond it).