Wandering Thoughts archives

2020-12-25

The expiry time of Certificate Authority root certificates can be nominal (or not)

The recent news from Let's Encrypt is Extending Android Device Compatibility for Let's Encrypt Certificates, which covers how Let's Encrypt is going to keep their certificates working on old Android devices for a few more years. The core problem facing Let's Encrypt was that old Android devices don't have Let's Encrypt's own root certificate, so to trust LE issued certificates they rely on a cross-signed intermediate certificate that chains to IdenTrust's 'DST Root CA X3' certificate (cf). The problem is that both this cross-signed certificate and DST Root X3 itself expire at the end of September 2021.

DST Root CA X3 expires in 2021 mostly because it was generated at the end of September 2000, and people likely thought that 20 years ought to be long enough for any root certificate (the CA world was a different place in 2000). The LE cross-signed intermediate certificate expires at the same time because you don't issue TLS certificates that expire after the certificate they're signed by. Well, normally you don't. The workaround Let's Encrypt came up with is to generate and have cross-signed a new version of their intermediate certificate that is valid for three years, which is past the expiry time of DST Root CA X3 itself.

(Multiple versions of a single certificate can exist because a certificate is only really identified by its keypair and X.509 Subject Name.)

You might wonder how this works. The answer is that Android in particular and software in general often treats root certificates rather specially. In particular, the validity dates for root certificates are sometimes essentially advisory, with it being enough for the certificate to be in the root 'trust store'. This treatment of root certificates isn't necessarily universal (and it's certainly not standardized), so it's possible for some software in some environments to care about the expiry time of a root certificate, and other environments to not care.

(For instance, as far as I can tell the standard Go TLS certificate verification does care about the validity times of root certificates.)

There is a philosophical argument that once you've made the decision to put a CA root certificate in the trust store, you shouldn't declare it invalid just because a date has passed. In this view, validity ranges are for certificates that can be replaced by the websites supplying them, which root certificates can't be. There's another argument that you should limit CA root certificate lifetimes for the same reason that you limit the lifetimes of regular certificates; things change over time and what was safe at one point is no longer so. Perhaps in another decade there will be general agreement over how software should behave here (and all software will have been updated).

(In practice, I believe that people making long-lived pieces of hardware and software that have to use TLS should demand and turn on an option to not enforce root CA lifetimes. People always stop making software updates after a while, and that includes updates to the list of trusted CA root certificates. But how to deal with TLS and general cryptography on systems that have to live without updates for 20 years or longer is something we haven't figured out yet.)

CertificateAuthorityRootExpiryMaybe written at 23:44:50; Add Comment

2020-12-09

A probable benefit to enabling screen blanking on LCD displays

A little while ago, I wrote about remotely turning on console blanking on a Linux machine, and in it I wondered if blanking LCD displays really mattered. The traditional reasons to blank your screen were a combination of CRT burn-in worries and the major power savings to be had from powering down a CRT display; LCDs mostly don't have burn-in, and they have low power usage. But today I realized that there is still a benefit to blanking out your idle LCD displays, or more exactly to getting them into power saving mode.

Standard LCD panels are backlit from a light source; originally this was one or more CCFL fluorescent lights, but these days most displays use white LEDs as the backlight. This backlight is always on if the panel is powered up and displaying any lit pixels at all, and I believe that it's still left on even if the panel is displaying all black (so that when some bit of the display switches to non-black, you don't have to wait for the backlight to come up). When a LCD panel switches to power savings mode, one of the things it does is turn off the backlight.

Turning off the backlight saves some power, which is nice, but it also lengthens the backlight's lifetime. Both CFL and LED backlights eventually dim or fail entirely, and how long this takes depends partly on how long they're on for. This means that powering down the backlight can lengthen the backlight lifetime, especially for panels that won't be in use for a significant amount of time.

(It's probably better for a backlight to stay on than to be toggled off and then back on frequently, but these days many office LCD panels are probably spending weeks or months in power saving mode. Mine certainly are.)

With that said, I don't know how long the lifetime is for typical LCD backlights, and thus how much this matters. Apparently it's common for LCD panels to be rated for 50,000 hours of operation before they fall from full brightness to half brightness, but this can be extended if you don't run your panel at full brightness to start with. If your (work) LCD display already spends half its time off (between evenings, night, and weekends), that's already over ten years.

(And these days many people's home LCD displays are seeing many more hours of usage per week than they were before, while work displays are often getting a nice long break.)

LCDBlankingBacklightWin written at 23:46:17; Add Comment

2020-12-04

Some thoughts about low power loads and power supply efficiency

I was recently reading another guide to power supply units (PSUs), which repeated the common advice that you shouldn't over-size your PC's power supply because its efficiency drops significantly at low loads. The general guideline I've read is that a PSU needs to operate at around half load for optimal performance, and it's common for a power supply's efficiency to plummet below 15% or 10% of its load. This time around, reading all of that made me suddenly twitch.

Both my home machine and my office machine have 550 watt PSUs, and they often draw only 40 to 60 watts. My home machine has to work hard to get about 150 watts of power draw, which is under 30% load. This means that I am definitely on the comparatively not great portion of the PSU loading curve.

(How bad it is is an interesting question. Both machines have the same PSU, certified as an '80 Plus Gold' efficient unit. Via Wikipedia, I discovered that certification reports are online here. This contains a test down to an input of 66 watts (giving 56 watts of output), at 84.6% efficiency. This seems not all that terrible to me.)

Does this matter? On the large scale of things, I think probably not. Almost all of the reported power draw from these machines gets turned into heat in the end (some of it turns into noise and air motion from fans). More or less PSU efficiency only changes where the heat is generated, and it may be better to generate the heat in the PSU if the PSU is better ventilated.

On the small scale of things, I would rather generate less heat in total while getting the same amount of work done as fast as before (at least during the summer). But at the same time, low power PSUs are apparently not a very popular market segment, so there aren't many options that are highly efficient (especially if you don't want to spend an arm and a leg). It's possible that my current PSU, oversized as it is, is still my most efficient option for machines that idle around 50 watts of power draw.

The corollary to this low load issue is that this means my power consumption numbers are not quite measuring what it looks like. When I measure an idle power draw of 66 watts for my work machine, that's the PSU's input power; it's actually outputting 56 watts to the motherboard, the CPU, and other components. If I changed the PSU to a higher efficiency one, the input power draw would drop although the power consumption of the components hasn't changed (and similarly for a lower efficiency PSU).

The measurement is fair and accurate in the sense that it's measuring the power usage of the entire system, including the PSU. But it means that I mostly can't make confident declarations about the relative power usage of various components of my machines, because the measured power draws are affected by both differences between PSUs and differences in PSU efficiency at various load levels.

(Since my home and office machines have the same PSU, one of these factors is eliminated in that comparison. But if I compare these machines to my previous set of numbers, the PSU is definitely a factor. My 2011 machines used the PSU supplied with the case, an Antec Neo Eco 620C, which was likely only 80 Plus Bronze and 82.7% efficient at a 10% load draw of 77 watts or so.)

PSULoadEfficiencyEffects written at 00:28:51; Add Comment


Page tools: See As Normal.
Search:
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.