Open BenBE opened 2 weeks ago
Thanks for your contribution and summarized. It is so nice to have you to summarize those
Yes, I've read the requirements and consulted some CA repo about that. Although using a private key that you didn't create yourself is doing it wrong, in reality, it is more like an ethical suggestion, not a regulation. As an example, you can share the key and cert bundle with your outsourcing developers, which is also violating the first one de facto. (and technically, if you use Cloudflare or Github Pages or Wix, you are not using a private key created by yourself anyway) If we assume we are virtually in the same development group, that will make sharing the same key for development a totally sensible action, although you may argue the "hidden agenda" of the development group’s act is not truly sincere.
The reason behind our key being revoked is based on "suffered a Key Compromise to the public", which is totally sensible. As the CA nature, I totally support the act of the CA revoking the key due to "potential" harm to the client as the private key being compromised to the public, which makes the key no longer secure. So we are looking for a solution in this angle. In fact, I am keeping in communication with three major CA, and we all agreed as long as the "key is not compromised to the public", it will not be their business to control how their subscribers use their key pairs.
Thus, one of the main possible ways is, which I hope in the long run can achieve, is signing with a major CA with an unlimited issuing on the same domain name pricing, but it could be slightly expensive. (but actually not rocket expensive, more like a corporate plan level pricing), so it can provide different users with their own key pair. (again, using a private key that you didn't create yourself is just a "should do" suggestion, not really a regulation or the reason why the key revoke, Cloudflare technically doing the same thing)
But anyway, the worst situation will be (lack of money), we can still use as a non-HTTPS tools. :D
p.s. I have a law background. It is ethically not correct (not truly sincere using something), but not sincere doesn't make it illegal or breaking the regulations.
But still, I think you are really helpful and I truly thank you for your work. It takes me many hours to do the research, but you helped us to summarize it for everyone, which is really important. For a production environment, we must let all developers know it is extremely important to protect your private key, and leaking a private key can really result in damage to your product. So, your summary is so important, that's why I tag a Star in this discussion.
I thought, that by pointing at the very document that causes your certificates to get revoked repeatedly, I could maybe cause some rethinking of why the overall project is a bad idea, but well … Hope dies last, but it dies.
That said, counter to your point regarding being a lawyer, I should maybe add, that I have worked for a CA as software lead. So if you can stop sputtering my name all over the place, representing things as if I were to endorse this project, I'd be most grateful. This also includes removing mentions of my name in any Git commits.
Formal stuff aside, on to the technical stuff.
Unless the only thing you see of a "LHD developer" is a CSR with their public key, you still do not have an improvement over the status quo. And even then, any "LHD developer" can technically impersonate and MITM any traffic on your domain: This includes spoofing your get.localhost.direct
website. Thus the more (private) keys exist for your domain, the more likely is a risk of compromise and attack. The current risk analysis for this project is (to put it mildly) lacking.
On to your "ToS": Legally they are "interesting"; and that's not the positive kind … The construct you create effectively creates an unregistered entity with shared, unlimited liability, where anyone could be sued just because someone else did something wrong. And I doubt they are actually enforceable.
Which leaves the other point regarding the CABF BR: Not part of the text I quoted (but just around the corner in section 9.6) are some requirements for CAs regarding applicants, one of which is that the CA should be able to enforce their ToS against the applicant. The applicant on the other hand is required to ensure the private key is kept under their (sole) control, which you simply cannot if you are distributing it to random people. I your earlier reply you mentioned hosting and cloud providers. While these technically do the same (generate a key, request the certificate), they are acting on behalf of the applicant and thus also need to ensure, that the documents they see (including private keys) are properly protected. In your current setup, you are not acting on behalf of some "LHD developer", but as a service provider who offers the service of leaking their own private key to anyone who asks (BTW: you might have noticed my mail regarding keys used in the past, looking forward to a reply on that one).
Also, by providing a service, you technically fall under the GDPR and similar regulations.
And one last point: One thing currently mostly brushed under the carpet is the whole question of revocation, which going back to the CABF BR, requires the applicant to cease using the certificate once it's revoked. You can't enforce this even if you were to put it in the "ToS" unless you had proper controls in place.
TL;DR: Teach people how to do ACME to setup proper certificates automatically instead.
Hi BenBE,
You've got some good points. And for me, it is a very good learning experience to discuss with you. localhost.direct is a non-revenue project, and I am happy to use it on my own so I make it accessible to everyone. A bad idea doesn't make an idea that should be terminated. Let's Encrypt is also a bad idea, but it doesn't make it a helpful service.
Despite our discussion, I still think you've provided me with many insights, and I do think you are in good faith and a good developer. IT IS A BAD IDEA, of course, but it WORKS. ACME sometime is really not a choice for some people, so early-stage developers are using their company computers to learn coding, and they are unfortunately really not supposed to focus certificate stuff at this early learning stage. Programming is a very steep learning curve; it is extremely difficult at the beginning. And they really need something like this. As an ex-software lead in CA, the community really needs your insight on helping us find out a way that works within the scope and working "just OK", even if it isn't a perfect idea.
//Upinel
Personally, this project is non-revenue project for the developers' community. I have nothing to lose if it ceases to exist. Ultimately, I can still use it for my development work regardless how it goes. The only downside is the community that genuinely needs it.
So, please share your knowledge to help it become "just OK". The community needs you.
Without trying to spoil your fun, but the way this project is setup is in violation of the CA/Browser Forum Baseline Requirements section 9.6.3. In particular:
Furthermore you can take this even as far a section 4.9.1.1 of the same document:
Emphasis mine …
Or let's summarize:
In particular: Even if you were to implement a portal website where each user would receive their own key/certificate pack (good luck with rate limits on Lets Encrypt services), you are violating the first point. The current implementation of things violates the second point.
TL;DR: Just don't do this. Learn how to run ACME, certbot, Caddy, dehydrated, or any of the many alternatives locally for yourself without relying on third parties to generate a key for you.
NB: All globally issued certificates that are trusted in browsers by default are publicly visible. For this project's domain that list can be seen here.