Do you support Code sign certificates?
Right now we are planning to issue certificates only for TLS server authentication, and not for any other purpose.
Code-signing certificates as they’re used today are part of systems that try to decide whether a software source is malicious or legitimate. I don’t think Let’s Encrypt could easily play that kind of role when issuing certificates free of charge with an automated process without checking the real-world identity of the applicant. We could confirm that a code signing certificate applicant controls a domain name like iurewnrjewknkjqoiw.biz, but that doesn’t give users or operating system developers much ability to know whether software that that applicant publishes is trustworthy or malicious.
Is there a hidden message in this domain name?
Nope! Just an example of a domain name that someone could easily get with minimal investment.
In the future, could it be considered to add an exception to this, by allowing acknowledged open-source software to benefit from code signing certificates? There are several CA which have such programs.
@don-vip, this might not be a good fit for Let’s Encrypt because we’re focusing on certificates that can be issued in a completely automated way (which DV certificates for TLS servers can be). That allows us to issue certificates free-of-charge on a large scale. It seems to me that people expect code-signing certificates to incorporate some kind of identification verification of the subject, in the way that OV or EV certs for TLS do. That’s not something that we could do robotically; we’d need to have some kind of offline contact with the outside world to confirm offline identities.
Yes, the “outside world”.
FWIW, I would argue that a domain-validated code signing certificate definitely has some value. Since software is usually distributed as download anyway nowadays, associating the author with domain seems quite natural. For example, if I download the latest Firefox and the binary is signed by whoever controls mozilla.org, I can be pretty sure that it is legit.
OTOH, knowing that someone validated the legal paperwork for Mozilla Foundation does not add much trust, if any at all. Someone could register a 100% legal “Mozilla Corporation” somewhere in the Caribbeans and get a valid code signing cert for that.
I have no idea how difficult it would be to get OS vendors on board for this approach, but I think it’s worth at least considering it. Having domain-validated code signing certs could solve quite a few pain points, especially with open source (which often does not have a company associated with).
I completely agree. Just an example: When I install FileZilla, Windows tells me it is signed by “Tim Kosse”. How does the average user know that “Tim Kosse” is the legitimate author of FileZilla? I cannot even find an impress on the Filezilla website to check the name. Wikipedia knows, but how trustwhorthy is that?
If the next release would be signed by “Bart Simpson” I cannot know whether Bart joined the FileZilla project or tries to attack me. If it would say “Signed by the Owner of filezilla-project.org”, I would at least know that the one who signed now has the control over the site where I got the download link from. So this is dangerous if the attacker gets control over the domain? With the current system, assume an attacker has control over filezilla-project.org. He could easily lead me to some malicious download signed by “Bart Simpson” and I would not notice a problem, as I have no clue whether Bart Simpson is trustworthy (well, okay, in this case, …).
there are a couple of other challenges with code signing certificates
A) Only certain languages support code signing and verification
B) Other ways to protect users against code: PGP signatures but once again this relies on you trusting PGP code
MD5 hasshums - this relies on you to trust the website publishing the hash sums has not been altered
Overall code signing is a fairly complex and young field
Most code is singed or hashed and then that hash is published for others to verify
I believe the next iteration of this will be blockchains which will allow a consensus and a public record of code and their signatures.
Validation of publishing houses/open source projects can then be potentially centralised which will bring more trust.
There is a mechanism that Mozilla has been using (which is not at all the only work in this area):
I think they are further along than they’ve documented there.
However, the Windows code signing model seems to be coming at this problem from a rather different direction.
The Windows notion seems to be that users find some code “out there in the world” and then try to use it on their system, and then are confronted with a question of “who published this code?” and “is the publisher of this code somehow OK?”.
The Mozilla notion which we also see in other transparency projects and arguably in Unix package management is more like “I want to get software from Mozilla; where is it and how can I make sure that the software they give me is really from them?”.
This is to say that in the Mozilla approach users already know exactly which publisher (or distributor, like Canonical or something) they want the code to come from, and then the engineering question is how to double-check that what they got is really from that publisher. Whereas in the Windows approach, it seems like users encounter things in kind of random ways (maybe through advertising or marketing or social channels?) and then the engineering question is how to double-check that what they got is from somebody kind of OK or that there is some kind of entity accountable for its non-maliciousness.
From our perspective and use as a dev and for projects from my company, we’ve always used CodeSign with automated request (not extended nor manual contact options) and considering it’s automated and you can’t really 100% guarantee it’s legit, is more of an extra step towards security than a 100% secure seal that states “this is, for sure, legit and non-malicious software”. Even with a manual check you can’t really guarantee that software will be legit and it won’t contain malicious code: take CCleaner issue a while ago as a practical example of that.
From our perspective its more like: “Owkey, I’ve downloaded it from their website and with their signature. Windows does not complain about it anymore, browsers can download it and my AV or internet banking plugin is not blocking it anymore so it sounds legit”.
I do understand that the whole world is not about this same thinking, but I assume that an automated check could be possible using domains as it is done today and that this indeed have some value. For me (and for my coleagues), if you need (or want) some deep security, 100% proven and sealed with double extended manual validation, this could be an “opt-in” feature. So, in this case, if you need this type of secure certificate, you can buy one from the super.trusted.inc.com (or even from Let’s Encrypt, who knows?), just the same way you can do for SSL/TLS certificates with extended/manual validation and thousands of dollars of warranty
Since when is Code Signing used to see if code is malicious? That’s not even possible.
It’s used to verify the origin and the integrity of the code.
Just throwing this out there as an idea - Keybase uses a public gist as a way to verify that you are you.
Could LE use a file in a git repo the same sort of way?
Speaking as a volunteer… I don’t think so, since Code Signing need to use things more than “social media accounts”, or your phone number etc… The process of request a code signing certificate is similiar to request a Organization Validation TLS certificate.
Also, it might be a bad idea to use gist to host some of the personal information (you don’t want your passport number, street address, driver license number or social security number exposed to the public…)
With code signing is still possible a software is malicious. There is nothing like code signing protects from malicious code. But the point is that code signing refer to the creator. App cannot be changed for other and That’s the point ! Why letsencrypt not offer a signing certificate based on domain? With the same authentication methods, will be possible know if a software come from the legitimit owner of mysoftware.com domain for example
Couldn’t they confirm that by downloading from
https://mysoftware.com/? For example, you can tell that this version of
certbot-auto is published by
eff.org because it comes from
If many users won’t take this precaution, can we expect that they’ll take the precaution of looking at the domain mentioned in a hypothetical code-signing-enabled DV certificate and thinking about whether it belongs to the organization that they expect?
(I can think of several reasons why this isn’t exactly equivalent in its security properties or in the options that it gives to the software publisher, but I’m curious about what properties you’re looking for here.)
Also, I’m not very familiar with vendors’ root programs’ policies on code signing certificates, but my impression is that they generally don’t allow a code signing certificate to be issued to a domain name rather than to an identified person or legal organization. The CA/Browser Forum had a draft on code signing which was published at
and later published as a separate working group document (not adopted by the Forum)
Point 14 of Microsoft’s root program policy at
says that CAs that issue code signing certificates must follow this document.
But in the document, the only allowable verifications are the identity of an organizational applicant, or the identity of a individual applicant. (See section 11 of the Minimum Requirements document.) That is to say that these draft rules don’t allow any equivalent of domain validation for code signing. The verification methods that they do allow require human labor, and so these certificates wouldn’t be practical to issue free of charge. So I’m under the impression that Microsoft’s root program (and perhaps also other vendors’ root programs) don’t currently permit code signing certificates to be issued to domain names.