Hi @jamesxt94,
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
https://dl.eff.org/certbot-auto
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.