1) For better or worse, code signing certificates are expected to come with some degree of organizational verification. No one would trust a domain-validated code signing cert, especially not one which was issued with no human involvement.

2) App stores review apps because they want to verify functionality and compliance with rules, not just as a box-checking exercise. A code signing cert provides no assurances in that regard.

They can just do id verification instead of domain, either in-house or outsource it.

app store review isn't what I was talking about, I meant not having to verify your identity with the appstore, and use your own signing cert which can be used between platforms. Moreover, it would be less costly to develop signed windows apps. It costs several hundred dollars today.

Azure has a service ('Artifact Signing') which is $10/month for signing Windows executables (not Windows Store apps, which don't need it.)

That's pretty reasonable, considering it is built in to all the major code signing tools on Windows, they perform the identity verification, and the private keys are fully managed by Azure. Code signing certs are required to be on HSMs, so you're most likely going to be paying some cloud CA anyway.

This is wild, thank you so much!! I was struggling with these costs for a long time!! Why is this not more well known? I researched this a lot and it was going to cost me at minimum $500~ over 3 years with the cheapest providers. Let me see if my specific use case can work with them.

I owe you one @briHass :)

I see how this would be useful once we take binary signing for granted. It would probably even be quite unobjectionable if it were simply a domain binding.

However, the very act of trying to make this system less impractical is a concession in the war on general purpose computing. To subsidize its cost would be to voluntarily loose that non-moral line of argument.

I don't understand where the argument is. Being able to publish content that others can authenticate and then trust sounds like a huge win to me. I don't even see why it has to be restricted to code. It's just verifying who the signer is. More trusted systems and more progress happens when we trust the foundations we're building. I don't think that's a war on general purpose computing. I feel like there is this older way of thinking where insecurity is considered a right of some sort. Being able to do things insecurely should be your right, but being able to reach lots of people and force them to use insecure things sounds exactly like a war on general purpose computing.

Technologies cannot be normatively evaluated without considering the power structures they facilitate.

Consider secure boot; assuming it's properly implemented, could defend against an entire class of attacks—evil maid: if a third party physically compromises your machine while you're away to install malware, you'd be alerted or stopped from booting the modified image. This is a technical statement. Now whose keys are actually trusted to sign these images? The answer is whatever power dominates in the supply chain: Microsoft, on desktop devices, and the vendor on mobile.

In the case of Microsoft, the public indignation eventually forced them to open this system up, letting the poweruser delegate their agent freely and without manufacturer's coercion. But what about Android, where the natural market forces did get the upper hand: most phones remain locked from disabling secure boot, even fewer let you enroll your own keys. They result is that most Android phones cease security updates only a few years after manufacture, the vendor's own software riddled with obvious faults (like filling a user-inaccessible partition with logs that never get wiped, even after factory reset) and known CVEs, yet nevertheless remain attested as secure for high-assurance applications like banking, as determined by Google. This hypocrisy isn't accidental: the system's real aim was not to secure the user, but to secure its monopoly, instrumented by privileged Google Play Services, harvesting data beyond what any SDK can.

I myself regularly rely on attestation—my phone runs Graphene OS and my laptop self-signs its kernel for secure boot—but I recognize that these technologies in themselves are predisposed to misuse by anti-competitive corporations and repressive regimes.

Imagine government ID backed app signing became the norm for app stores. There will no longer be open-source utilities, like scientific calculators, notes, and budget planners, as they would not bear the certification fee what is effectively volunteer work, instead replaced by their ad-ridden copycats mass-produced in a software sweatshop, featured alongside or, through malicious ads, directing to assorted malware, still just as prominent as before, signed using passport details of random people off the street, taken down as late as they can, because Google enjoys a steady revenue stream from their repeated publisher verifications and AdSense spots. And that's to say nothing of censorship circumvention tools and other politically inexpedient software.

I think you're changing the topic here. But i'll bite a bit, we're talking about let's encrypt here, so for every argument you made, it would be let's encrypt issuing the certificates. All the "open source" use cases you have can also be supported by them.

The whole point of let's encrypt doing this would be to reduce the fees for open source devs and poor devs in general. But ultimately, software published to the public is a matter of consumer safety and welfare. to that end, if you have a solution that enables operating systems to authenticate and review software before consumers are exposed to it, feel free to suggest an alternative, short of that, too bad for the open source dev. Nothing stoping you from using alternative devices. You don't have any entitlement over operatins systems or hardware sold to the public. The needs of software developers as a whole is not important in the slightest bit when it comes to consumer devices and software. Just the same as the plumbers needs are irrelevant when it comes to evaluating the safety of water and sewage pipes, or the construction person's needs are irrelevant when it comes to evaluating the safety of the building they're working on.

If construction worker claims they don't need regulatory certified construction materials because that means random people building cabins in the woods can't sell their house, too bad right? They can still build their own cabin and live in it, but to sell the cabin house it must pass inspection (fees), zoning requirements, accessibility and fire safety requirements,etc.. why is your software dev industry so special?

And yes, microsoft and google get to police things, just like in every other regulated industry there are professional certification boards. You need to pass the law BAR to be a lawyer, you need to pass the medicine BAR to practice medicine on the public. And those BAR associations are made up of industry leaders. Nothing prevents you from going to medical school and treating your own self without passing the BAR. Nothing stops you from writing your own software and using it. but when other people use it, they expect the government to keep them safe from malpractice and harm, that supersedes any needs or desires you may have for open source. You can even argue that it should be free, and that's the whole point of this, let's encrypt made TLS certs free, maybe it can make code signing/dev auth free too! But if it doesn't ,i consider it gross incompetence and dereliction of duty, if the government doesn't require software signing and secure boot on every consumer accessible software system.

Would be cool. But since they’re a non-profit, they would need some way to make it scalable.

I see no problem with outsourcing id verification to a trusted partner. Or they could verify payment by charging you $1 to verify you control the payment card, and combine that with address verification by paper-mailing a verification code.