B (15:11)
Okay, so I'm going to spend one more story on this and then I'm going to leave it alone. I want to do it because the amount of feedback I've received from a range of our listeners who whose lives are impacted by certificate authorities one way or the other has been extensive. The subject line of the email I received from Digicert, my certificate authority, last Wednesday. Okay, just made me shake my head. The subject was in the email. Urgent. It started off urgent. Revalidate domains expiring February 24th due to new 199 day validity requirement okay, so here's what they wrote with their with great urgency. Dear valued customer, we're reaching out with an urgent request to check your certificate domain validations before February 24, 2026, as we communicated in previous emails. February 24th. By the way, that's today, right? Today we're recording this on February 24th. February 24th is the date when domain validation reuse periods will shorten to 199 days, down from 397 days in accordance with the CA Browser Forums Ballot Science 081 version 3. Our records indicate that you or your sub accounts have existing domains that will expire on February 24th because of this change. If your systems require immediate certificate issuance, your issuance could be delayed if you don't check and revalidate these domains before February 24th. So what do you need to do? DigiCert Cert Central with a circle R because that's needed to get that registered, now displays which of your current domains will expire on February 24, 2026 due to the change to 199 day domain validation reuse periods. Steps for reevaluating domains that expire and then they go through it like, you know, Rick and Roll of how to march through their user interface and then they finish with we're here to help. We understand industry driven. Right? They had nothing to do with it. Despite the fact that they're the biggest CA there is in and voted for all this. We understand industry driven compliance changes pose significant challenges and we're standing by to assist you. Please don't hesitate to contact your Digicert account manager with any questions or concerns about the change to 199 day domain validation reuse periods. Thank you for trusting us with your digital with your digital security. Signed the Digicert team. Okay, so since digicert, a prominent, if not the prominent voting member of the CA browser forum, voted themselves to bring about these changes, it seems a little odd for them to be sympathizing with their customers over the inconvenience that these changes create. To be straightforward, they would state that these changes have been made in the interest of improved security. Okay, we might disagree with that, as we, you know. As we know I do. But at least then they would be genuine. What, what, what puzzled me in their note, which I read closely, was their statement that our records indicate that you or your sub accounts have existing domains that will expire, blah, blah, blah, on February 24th. As we know, it's, it's never the case that anything is ever done that causes existing certificates to suddenly become invalid. Right? They said your issuance could be, you know, your systems require immediate certificate issuance. Your issuance could be delayed if you don't check and revalidate these domains before the 24th. Again, as I was saying, it's never the case, thank goodness, that anything is ever done that causes existing certificates to suddenly become invalid. You know, obviously, revocation notwithstanding, it's always the case that the not valid after date continues to be honored. When you think about that, it's clear that a certificate that contains a built in not valid after date means valid until that date. And there's no way to after the fact have that no longer be true because it's, it's bound into the certificate. And this is why I went to all the trouble last week to establish a new code signing relationship with ident trust while they, while three year certificates were still allowed by the CA browser forum for code signing. And as I mentioned at the top of the show, I am now the proud holder of a code signing certificate that will be valid until February of 2029. And nothing that happens between now and then, no matter what new insanity the CA browser forum may enact, will change that. So the answer to the mystery of what Digicert means here is the phenomenon I spoke about last week, which is the new need which they created to decouple certificate qualification from certificate is issuance. Since a certificate, once issued, will always live out the duration of its valid life unless it's revoked. Back when certificates were issued for 10 or, or even five years, the qualification for that certificate was determined at the time of the certificate's issuance. And that was all that. And, and that would be that, that, that, that was it, you, you verify that you qualify. Here's your 10 year certificate, see in 10 years. But with the changes that are, you know, bringing about this shortening of certificate lifetimes, automation is effectively required. And you know, they're going to be seeing that more and more. As we know the industry intends to keep marching certificate lifetimes downward until they reach a maximum of 47 days in 2029. We're about to drop to 200. That's happening in the next week or two to 200 days maximum. Then it will be 100 where it holds for a couple years, then finally lands on 47 days. So the issuance of organization validation certificates, which is what Digicert produces, needed to be decoupled from the qualification to receive those issuance. Decoupled from qualification before the middle of next month. The CA Browser Forum would allow organizations to go up to 825 days between qualification intervals. So that's around 27 months and before an organization needed to be revalidated. But those 825 days now drops to 398 days, which is what Digis search letter was about. They're saying that one or more of the validations that they performed for Gibson Research Corporation's identity occurred more than 398 days ago until today. Literally today, February 24th. And that was just fine. But as of today, February 24th, that's no longer true. The validations that were, that were, that were valid yesterday are no longer valid today. So anybody who would need to reissue a certificate soon needs to recognize that although they could have done so yesterday, they can't do so tomorrow. Again, just craziness. But that's the way this industry is being played. So you know, don't just go thinking that all you need to do is push a button to issue yourself a certificate. Oh no, your button has been disabled. You no longer qualify until you've had the ch. You know, they, your, your authority have had the chance to look you up and down again, make sure you're still you. And what's more, that will now be annual. Oh yes, these wild times where you could go, well, yesterday, 825 days. But once upon a time, five years, 10 years, no problem, those are over. So this explains why once my previously paid certification with Digicert is over, in two years, I'll be happily dropping OV these organizational verification certificates in favor of the much cleaner and simpler DV domain validation certificates that let's Encrypts Automation has been gleefully issuing now to the vast majority of the Internet, to anyone who wishes to bring a server online. So I, I, I, I, all we could do is go along with it because we have no control. Okay, so I know you were up to speed on this, Leo, because you, you, you reacted to it when I was saying I was going to talk about this. We have another example of lawmakers apparently thinking we don't know how you techies are going to do it. Yeah, but that's not our problem. We're going to make it a law so that it becomes your problem. And I just wanted to point out thanks to our listener Tom Minick for bringing this little tidbit to my attention. Tom sent a link to the reporting on the well known and the reporting which appeared and was covered by the well known and popular Adafruit website. Adafruit ADA F R U I T for those who may not be aware, is a highly regarded hobbyist maker, hardware, electronics website and retailer. They posted the news of this new num skull legislation under their headline California's new bill requires DOJ approved 3D printers that report on Themselves. So here's what Adafruit wrote. They said California's new bill requires Department of Justice approved 3D printers that report on themselves targeting general purpose machines. Assembly member BAUER Khan introduced AB 2047, the quote California Firearm Printing Prevention act on February 17th. So just recently the bill would ban the sailor transfer of any 3D printer in California unless it appears on a state maintained roster of of pre approved makes and models Certified by the U.S. department of justice as being equipped with quote firearm blocking technology. Manufacturers would need to submit attestations for every make and model. The DOJ would publish a list. If your printer is not on the list by March 1, 2029, it cannot be sold. In addition, knowingly disabling or circumventing the blocking software would be a misdemeanor. And it gets worse. Much worse. Okay, is everybody sitting down? Adafruit continues, We've been tracking this pattern. Washington States HB 2321 requires printers to include blocking features that cannot be defeated by users with significant technical skill. You know, good luck with that. On open source firmware, New York's budget bill S.9005 buries similar requirements in Part C, sweeping in CNC mills and anything capable of subtractive manufacturing. California's version adds a certification bureaucracy on top, state approved platforms, state approved software control processes, state approved printer models, quarterly list updates, and civil penalties up to $25,000 per violation. As Michael Weinberg wrote after the New York and Washington proposals dropped, accurately identifying gun parts from geometry alone is incredibly difficult. Desktop printers lack the processing power to run this kind of analysis, and the open source firmware that runs most machines makes any blocking requirement trivially easy to bypass. Okay, so I'll interrupt to note again. Once again, you know, when when printers that can print weaponry are outlawed, only outlaws who wish to print weaponry will own outlaw printers. Nothing will be accomplished to curtail the fact that a 3D printer can be used to print a dangerous machine, Adafruit continues. The Firearms policy coalition flagged AB 2047 on X, and the reactions tell you everything. John Leroux called it stupidity on steroids, pointing out that a simple spring shaped part has no way of revealing its intended use. The Foundry put it plainly. Quote Regulating general purpose Machines is another AB 2047 would require 3D printers to run state approved surveillance software and criminalize modifying your own hardware. Unquote. Adafruit continues, as we've said before on this blog when we covered Washington and New York, it doesn't matter if you're pro or anti gun. The state should prosecute people who make illegal things, not add useless surveillance software to every tool in every classroom, license, library and garage in the state. And as you can see, these bills spread. That's how a small group can push legislation into the entire country. First Washington proposed theirs, then New York, now California. Once these three states pass a law that's 20 to 25% of the country by GDP and population, and thus every manufacturer is forced to comply with a bad decision in order to stay in business. If you're a maker, educator, or manufacturer anywhere in the U S, even outside these states, this is a problem. It's a problem now. Adafruit's article mentioned Michael Weinberg. Michael is the executive director of NYU's Engelberg center for Innovation, Law and Policy. He's a board member of the Open Source Hardware association, and, as he describes himself, a maker of poorly made things. He's also, however, an astute thinker. And since I think this topic is extremely interesting and that our listeners are likely to find it so, I wanted to also share what Michael wrote in the wake of the New York and Washington state bills. The title of Michael's posting was 3D printers cannot effectively Screen for Gun parts, he wrote. This post is a handy reference for the technical reasons why requiring 3D printers to screen for gun parts is not an effective way to reduce guns or gun violence. I'm publishing it on the occasion of both New York and Washington state introducing bills to require this type of screening. In addition to a topic I've been researching for over a decade, the question of how to know if a 3D printer is printing a gun part is something I've spent a lot of time working on while overseeing trust and safety at a large 3D printing service provider. So consider that, you know he's been overseeing trust and safety at a large 3D printing service provider where the question of what is it we are printing on these with our commercial grade machines, you know, comes up. So he said this post is not about debating the larger legitimacy of gun control in order to focus on the technical reasons which why requiring 3D printers to identify and refuse to print gun parts does not work. It assumes that gun control is a reasonable and legitimate action of governments. Broadly speaking, it's responding to requirements that all 3D printers check prints to make sure they're not gun parts. If the part is a gun part, the printer would refuse to print it. The short version is that accurately identifying gun parts is incredibly difficult, and the hackable nature of desktop 3D printers makes it trivial to circumvent any requirements to even try. Here's the slightly longer version Matching files is fragile and anybody you know, we've talked about hashes, right? The whole point of a hash is that you want matching files to be fragile. So this is working against you here. He said the first reason that requiring 3D printers to identify gun parts is ineffective is because analyzing 3D files is complicated. Any attempt to identify gun parts will miss many parts that are actually for guns and may flag a number of parts that that have nothing to do with guns. You know, they're just kind of gun like expensive engineering design software is good at evaluating specific properties of a 3D file, like where mechanical stress will occur over a lifetime of use. However, even that software cannot tell you what a part actually does is that spring for a door, or a shock absorber or a catapult. This challenge is exacerbated by the fact that guns are just mechanical objects. That means that there are many ways to design any individual part, and many individual parts of guns will resemble mechanical parts with totally benign uses. Put another way, devoid of other context, a switch for a gun safety or looks a lot like a switch for a door. Broadly speaking, there are two ways to think about doing file matching. Algorithmic analysis is one. This approach imagines a piece of software that can analyze a file and determine with some level of certainty if it is a gun part or just a hinge. Assuming that this software exists, which it does not at the time of this writing, it is reasonable to expect that such an analysis would be reasonably computationally expensive. 3D printers do not have the onboard processing power to do this kind of analysis. Requiring that they include chips capable of this kind of analysis would fundamentally change the economics of 3D printer design, akin to requiring that all bikes include jet engines. And I'll interrupt Michael for a Moment to comment that he's not exaggerating how Totally inadequate any 3D printer is for performing any sort of complex analysis. 3D printers are extremely simple and inexpensive. I've owned a number of them. They have nearly no brain power themselves. They're extremely simple robots that read instructions from a USB stick or SD card. You know, there are some that fix a liquid resin using an image, and others that move a plastic extruder around in three space. You know, basically saying, move the plastic extrusion head from. From where it is now to coordinates X, y, and z. The resin fix images or the instructions with their coordinates were created outside the printer by a real computer that's running some sort of engineering drawing, design conversion software. Once the design is ready, it's converted into fabrication instructions, which are typically written to a storage device and, and then transferred to a standalone printer, which simply follows the instructions step by step without in any way understanding what it is that it's being asked to print that just isn't there. So these printers are inexpensive. I mean, they're really inexpensive, you know, hundreds of dollars only because, you know, they could not be any more rudimentary. They've just been stripped of anything that they don't need. Michael continues, of course, writing, the 3D printer could upload the file to a cloud somewhere and let the processing happen there. However, Internet connectivity is not a default feature on desktop 3D printers. You could require that all 3D printers maintain a constant connection to the Internet in order to operate. But again, that would fundamentally change how people use their printer. There are also many legitimate use environments where constant Internet connectivity is neither possible nor desirable. Of course, we immediately think of this as, like, what about, you know, malware downloading itself into our 3D printers because they now have Internet connections? It's like, no, please, let's not go there. And he says, and of course, this raises the question of who's responsible for. For maintaining that directory and keeping it secure, meaning in the cloud. So what about blacklisting? He asks. If it's not possible to analyze the true purpose of each file, it might be possible to at least. At least match them against a known database of gun parts. Right. This approach also has some serious shortcomings. First, there's the question of keeping that database up to date on the printer. That would require constant or at least regular Internet connectivity for the printer. That raises the same issues as discussed in the last section. Second, also as discussed above, analyzing and matching 3D files is computationally expensive. The most logical way to do that with the processing power of the 3D printer would be to use a hash table of known gun parts comparing a hash of the file to be printed against the table. The primary problem with both geometry matching and hash matching is that it's incredibly fragile. The smallest change that had no impact on the functioning of the part right one bit changed would completely change its hash, effectively hiding it from the blacklist. That would make it trivial for anyone to circumvent. Identifying which changes are functional and which are merely aesthetic is not easy. That's especially true if people are making those changes with a specific goal of tricking the printer into printing a gun part. You know, make a cosmetic change, change a tiny little thing, a little tick somewhere, and now it's it looks like an entirely different file because it's in a completely different hash. And as we know, that's the nature of hashes, he writes. 3D printers print themselves the second reason this proposal is ineffective is because 3D printers are made in an incredibly distributed way. There are dozens of ways to make your own 3D printer using open source user modifiable parts, even non open source printers or are highly hackable. And I the point he's making is you don't have it's not the only way to get one is not to buy one. You can make one, he says. As a result, there's no way to mandate that a technology that starts in a 3D printer remains in a 3D printer. The software that runs most printers is open source, meaning a single update would circumvent any screening measures. This places 3D printers at the opposite end of the spectrum from 2D printers. This was interesting. I hadn't thought about this before. He wrote anti counterfeit systems prevent 2D printers from printing currency. To the extent that these rules are effective, he says. Paran's not I'm no expert, but they are often cited in these discussions as successful models. He says it is because the 2D printing industry is fairly concentrated and proprietary. 2D printer companies are actively hostile to users who want to modify their products, significantly raising the barrier to hacking around any countermeasures. Desktop 3D printers are the opposite. They all trace their heritage back to open source printers, and users expect to be able to modify, extend and hack their own printers. That means that workarounds for a screening mandate would be easy to develop, distribute and implement. Many open source software packages might even include the circumvention by default, meaning users would implement it without even actively intending to do so. 3D printers are general Purpose machines. This post is focused on the technical challenges with requiring 3D printers to screen every file it prints for gun parts. Nonetheless, it would be incomplete without a brief mention of how potentially invasive this sort of requirement is. 3D printers are general purpose machines that can be used for good or ill. Just as we do not require the phone company to monitor every phone call in order to prevent customers from using phones to commit bank fraud, we should be wary of requiring our 3D printers to monitor every print in order to prevent one possible type of print. That type of invasion might be reasonable if it was effective. However, for the reasons described, it is unlikely to prevent even a modestly motivated person from using their printer to create gun parts. If an intervention is both highly invasive and unlikely to be effective, it's probably not an ideal policy, which I think is putting it mildly. So I think Michael did a great job of detailing the specific 3D printing issues which would surround any attempt to manage or control what a 3D printer can and cannot print. And while I have no interest in ever owning or printing a firearm, you
