5 ms·

> We think that revoking certificates based on questionable data discredits the certification system. It's hard to dispute this imo. There are many good reason

> We think that revoking certificates based on questionable data discredits the certification system. It's hard to dispute this imo. There are many good reasons certificates should be revoked, but the reasoning should be 100% public information, for both the vendor and users who may have trusted the original certificate. I'm building a desktop app, and the process to even get a certificate is absurd. Each CA has their own wildly different processes, and seemingly answers to nobody. I changed cert providers recently after Digicert suddenly raised their prices 400% on a whim, and it took a huge number of changing requirements, phone calls, 3rd parties, and over a month to receive the new one, despite already having an existing verified & still-valid signing certificate with all those details from an equally legitimate provider. I'd kill to see a modern service a la Let's Encrypt but for code signing. Something transparent, reliable, fast & trusted cross-platform (I can dream). Verifying identity is a hard problem, but it's really not _that_ hard a problem - there's plenty of fintech services that can reliably do sufficient KYC for banking in 5 minutes with a few id details and video call.

SyneRyder 6y ago
> I'm building a desktop app, and the process to even get a certificate is absurd... When switching providers, I don't suppose you tried K Software? Mitchell Vincent has fantastic personal customer service. Been a while since I last used his services, but he's always been patient & helpful when I ran into issues getting verified: https://www.ksoftware.net/code-signing-certificates/ https://www.ksoftware.net/code-signing-certificates/ That said, I've noticed a lot of big companies in the music industry stopped signing their software altogether and distribute it unsigned now. Doesn't seem to have hurt their sales - or maybe even improved it, there's less lag on Windows launching an unsigned app.
asdfasgasdgasdg 6y ago
There's another aspect of this situation that also discredits the system: that they can just go out and get a different cert from another vendor. How many such vendors are there? How long would it take for an actual bad actor to have all their certs discovered and revoked? If that time is long, then the certification process is of even more dubious value, since the bad guys would not be materially hindered by the certification requirement.
- gruez 6y ago
  "Security-in-depth": https://news.ycombinator.com/item?id=24193087 https://news.ycombinator.com/item?id=24193087
  - asdfasgasdgasdg 6y ago
    On some level I get it but aren't cash cards a thing? What actual level of identity and KYC do these cert companies do? How easy is it for someone without scruples to get another cert without revealing their identity? (Genuine questions: I do not personally know.)
    - deburr 6y ago
      Cash cards can be distinguished against at the merchant level by most payment providers (and often are to prevent delayed charge fraud).
- tgsovlerkhgsel 6y ago
  The job of a certificate authority is to verify an identity, not to vet that the holder is using the certificate only for good. As long as the CAs do that job (which is a separate issue), it's fine if John Doe can get 50 different CAs to certify that he is, indeed, John Doe.
  - ecdavis 6y ago
    Take a look at the "Baseline Requirements for the Issuance and Management of Code Signing Certificates"[0] - specifically section 13.1. Here's the most relevant excerpt: > A CA MUST revoke a Code Signing Certificate in any of the four circumstances: (1) the Application Software Supplier requests revocation, (2) the subscriber requests revocation, , (3) a third party provides information that leads the CA to believe that the certificate is compromised or is being used for Suspect Code, or (4) the CA otherwise decides that the certificate should be revoked. [0] https://cabforum.org/baseline-requirements-code-signing/ https://cabforum.org/baseline-requirements-code-signing/
  - 6y ago
AnthonyMouse 6y ago
The other consideration is that verifying identity is pointless, because malware authors don't actually use their own identities, they just pull a code signing certificate from the 1% of their already-infected users who have one. Then they go out and infect a million more users with it and get 10,000 more code signing certificates. If all you're after is some kind of rate limiting then forget about identity verification and just require proof of a unique $500 donation to a 501(c)(3). Not only would it be easier to automate, it would do some good in the world, and people would be a lot happier to see their resources go there than to some box checking bureaucrats.
- DaiPlusPlus 6y ago
  This is why code-signing certificates must be two-factor (e.g. embedded on a PIN secured smartcard where the private-key is protected from extraction by anybody). My Tucows certificate is still a single *.pfx file - whereas my arguably less-consequential AATL (Adobe PDF signing) certificate is stuck on a crappy USB device that requires me to install marketing-laden software for. I miss my old commodity smartcard-based certificates.
  - AnthonyMouse 6y ago
    Doesn't actually fix it: https://www.schneier.com/essays/archives/2005/04/two-factor_authentic.html https://www.schneier.com/essays/archives/2005/04/two-factor_... Your computer is unknowingly infected with malware, you go to do an update to your app, you insert your smartcard and enter your PIN, the malware signs the malware author's thing with it.
    - DaiPlusPlus 6y ago
      I understand the PIN is sent directly to the smartcard that performs the signing - not on the host PC - and it's required for each signing operation. So if malware did intercept the signature process and sign itself, I would notice that my originally intended software wasn't signed - that would hopefully be a hint to me that something was amiss and my computer was compromised.
batch12 6y ago
I agree that it would be nice to have a letsencrypt for code. The biggest hurdle I see is getting the the root trusted by OS vendors. While not impossible (the browser vendors did it), trust on these platforms may be a bigger issue since the code runs natively.
- austincheney 6y ago
  That’s less huge of a hurdle than it sounds. Root certs can be installed as part of an application installation or baked into a custom corporate OS image. Both of my employers have their certs installed in their corporate Windows images. To install the certs manually takes a bit of research. I recently wrote a Node.js script to do this in my application cross-OS using a Stackoverflow answer as a reference.
  - batch12 6y ago
    That's true, but then you don't need something like let's encrypt. If you're doing this for an environment you already control you can have your own CA. Unless you are proposing a solution where each installer for these applications bundle the root cert so only one need be installed to trust all others. That's an interesting idea.
MadVikingGod 6y ago
Let's Encrypt's argument for why all the fancy features that CA's offered boiled down to "These are more complicated ways of proving that you own a domain". So by automating the verification of ownership of a domain you could essentially run a CA for pennies per certificate, and give them out for free. Looking at application development I think a similar thing could be done, but what would we pin identity to? I don't know if there is one thing that every app has like a website.
- DaiPlusPlus 6y ago
  Registered company information and/or notarised identity cards.
- benlivengood 6y ago
  > Looking at application development I think a similar thing could be done, but what would we pin identity to? How about domain name? Whenever I install (Windows) software I rarely care about the mailing address or D.B.A. name; I look at the website address listed.
  - gruez 6y ago
    A domain name costs less than a dollar. A DBA or real-life identity cost significantly more. In addition, if I'm getting my software over the internet (99.99% of the cases), I'm already verifying the domain name via the browser (via tls), so it's not adding any additional security. If the server was hacked, the attacker can mint himself a new certificate and you won't be able to tell.
    - benlivengood 6y ago
      microsoft.com or debian.org would cost a lot more than $1 and I would trust signed or unsigned software downloaded from either a lot more than from a random domain name. Code-signing definitely adds the benefit of offline key management; there is less risk of signing keys being stolen than TLS keys. But the valuation of trust is rooted in the domain; if Debian has to revoke all their keys for some reason I'll trust debian.org over any other source for re-establishing a root of trust unless a significant fraction of the Internet and mailing lists are crying foul, and even then I would probably wait for control of debian.org to be settled before trusting any Debian repositories. I still think that demonstrated control of a domain is sufficient for verifying a code-signing identity, even automatically like LetsEncrypt does for TLS.

SyneRyder 6y ago

> I'm building a desktop app, and the process to even get a certificate is absurd... When switching providers, I don't suppose you tried K Software? Mitchell Vincent has fantastic personal customer service. Been a while since I last used his services, but he's always been patient & helpful when I ran into issues getting verified: https://www.ksoftware.net/code-signing-certificates/ https://www.ksoftware.net/code-signing-certificates/ That said, I've noticed a lot of big companies in the music industry stopped signing their software altogether and distribute it unsigned now. Doesn't seem to have hurt their sales - or maybe even improved it, there's less lag on Windows launching an unsigned app.

asdfasgasdgasdg 6y ago

There's another aspect of this situation that also discredits the system: that they can just go out and get a different cert from another vendor. How many such vendors are there? How long would it take for an actual bad actor to have all their certs discovered and revoked? If that time is long, then the certification process is of even more dubious value, since the bad guys would not be materially hindered by the certification requirement.

gruez 6y ago
"Security-in-depth": https://news.ycombinator.com/item?id=24193087 https://news.ycombinator.com/item?id=24193087
- asdfasgasdgasdg 6y ago
  On some level I get it but aren't cash cards a thing? What actual level of identity and KYC do these cert companies do? How easy is it for someone without scruples to get another cert without revealing their identity? (Genuine questions: I do not personally know.)
  - deburr 6y ago
    Cash cards can be distinguished against at the merchant level by most payment providers (and often are to prevent delayed charge fraud).
tgsovlerkhgsel 6y ago
The job of a certificate authority is to verify an identity, not to vet that the holder is using the certificate only for good. As long as the CAs do that job (which is a separate issue), it's fine if John Doe can get 50 different CAs to certify that he is, indeed, John Doe.
- ecdavis 6y ago
  Take a look at the "Baseline Requirements for the Issuance and Management of Code Signing Certificates"[0] - specifically section 13.1. Here's the most relevant excerpt: > A CA MUST revoke a Code Signing Certificate in any of the four circumstances: (1) the Application Software Supplier requests revocation, (2) the subscriber requests revocation, , (3) a third party provides information that leads the CA to believe that the certificate is compromised or is being used for Suspect Code, or (4) the CA otherwise decides that the certificate should be revoked. [0] https://cabforum.org/baseline-requirements-code-signing/ https://cabforum.org/baseline-requirements-code-signing/
- 6y ago

AnthonyMouse 6y ago

The other consideration is that verifying identity is pointless, because malware authors don't actually use their own identities, they just pull a code signing certificate from the 1% of their already-infected users who have one. Then they go out and infect a million more users with it and get 10,000 more code signing certificates. If all you're after is some kind of rate limiting then forget about identity verification and just require proof of a unique $500 donation to a 501(c)(3). Not only would it be easier to automate, it would do some good in the world, and people would be a lot happier to see their resources go there than to some box checking bureaucrats.

DaiPlusPlus 6y ago
This is why code-signing certificates must be two-factor (e.g. embedded on a PIN secured smartcard where the private-key is protected from extraction by anybody). My Tucows certificate is still a single *.pfx file - whereas my arguably less-consequential AATL (Adobe PDF signing) certificate is stuck on a crappy USB device that requires me to install marketing-laden software for. I miss my old commodity smartcard-based certificates.
- AnthonyMouse 6y ago
  Doesn't actually fix it: https://www.schneier.com/essays/archives/2005/04/two-factor_authentic.html https://www.schneier.com/essays/archives/2005/04/two-factor_... Your computer is unknowingly infected with malware, you go to do an update to your app, you insert your smartcard and enter your PIN, the malware signs the malware author's thing with it.
  - DaiPlusPlus 6y ago
    I understand the PIN is sent directly to the smartcard that performs the signing - not on the host PC - and it's required for each signing operation. So if malware did intercept the signature process and sign itself, I would notice that my originally intended software wasn't signed - that would hopefully be a hint to me that something was amiss and my computer was compromised.

batch12 6y ago

I agree that it would be nice to have a letsencrypt for code. The biggest hurdle I see is getting the the root trusted by OS vendors. While not impossible (the browser vendors did it), trust on these platforms may be a bigger issue since the code runs natively.

austincheney 6y ago
That’s less huge of a hurdle than it sounds. Root certs can be installed as part of an application installation or baked into a custom corporate OS image. Both of my employers have their certs installed in their corporate Windows images. To install the certs manually takes a bit of research. I recently wrote a Node.js script to do this in my application cross-OS using a Stackoverflow answer as a reference.
- batch12 6y ago
  That's true, but then you don't need something like let's encrypt. If you're doing this for an environment you already control you can have your own CA. Unless you are proposing a solution where each installer for these applications bundle the root cert so only one need be installed to trust all others. That's an interesting idea.

MadVikingGod 6y ago

Let's Encrypt's argument for why all the fancy features that CA's offered boiled down to "These are more complicated ways of proving that you own a domain". So by automating the verification of ownership of a domain you could essentially run a CA for pennies per certificate, and give them out for free. Looking at application development I think a similar thing could be done, but what would we pin identity to? I don't know if there is one thing that every app has like a website.

DaiPlusPlus 6y ago
Registered company information and/or notarised identity cards.
benlivengood 6y ago
> Looking at application development I think a similar thing could be done, but what would we pin identity to? How about domain name? Whenever I install (Windows) software I rarely care about the mailing address or D.B.A. name; I look at the website address listed.
- gruez 6y ago
  A domain name costs less than a dollar. A DBA or real-life identity cost significantly more. In addition, if I'm getting my software over the internet (99.99% of the cases), I'm already verifying the domain name via the browser (via tls), so it's not adding any additional security. If the server was hacked, the attacker can mint himself a new certificate and you won't be able to tell.
  - benlivengood 6y ago
    microsoft.com or debian.org would cost a lot more than $1 and I would trust signed or unsigned software downloaded from either a lot more than from a random domain name. Code-signing definitely adds the benefit of offline key management; there is less risk of signing keys being stolen than TLS keys. But the valuation of trust is rooted in the domain; if Debian has to revoke all their keys for some reason I'll trust debian.org over any other source for re-establishing a root of trust unless a significant fraction of the Internet and mailing lists are crying foul, and even then I would probably wait for control of debian.org to be settled before trusting any Debian repositories. I still think that demonstrated control of a domain is sufficient for verifying a code-signing identity, even automatically like LetsEncrypt does for TLS.