Maybe it's just the effect legalese sometimes has of making your head spin, but that looks like kind of a lot of "ifs" for something that's being touted as so universal it can justify killing HTTP.
A few requirements:
- You have not participated in the seizure of a
domain name that had ongoing lawful uses
- all information in Your Certificate regarding You or Your domain name is accurate, current, reliable, complete, and not misleading
- all information You have provided to ISRG is accurate, current, complete, reliable, complete, and not misleading
- You have taken all appropriate, reasonable, and necessary steps to secure and keep your Private Key secret
They can send you away even if you do everything they ask:
- ISRG may, in its sole discretion, refuse to grant Your request for a Let’s Encrypt Certificate, including for
reasons not stated in this Agreement
- ISRG may also, without advanced notice, revoke Your Certificate if it determines, in its sole discretion,
that … Your Certificate has become unreliable
- ISRG may also, without advanced notice, revoke Your Certificate if it determines, in its sole discretion,
that … information in your registration with ISRG or request for an Let’s Encrypt Certificate has changed
Those seem like fairly reasonable 'ifs' to have. They have to cover themselves and prevent abuse, or else no one will trust the certificates they issue.
They can't allow anybody who has ever been involved in a domain name seizure or no one will trust their certificates? I'm not following the causal chain there.
Why? It seems to me like it should be really simple: I prove I control domain X, they issue me a certificate for domain X. End of story. Does there need to be more?
What if someone hijacks a domain? Should they issue one then?
I'll say this, I don't want to see "Let's Encrypt" go on some moral crusade deciding not to grant a certificate to a website because that website contains offensive content, but their job is to verify at least somewhat the identity of the requester to try and stem impersonation.
That would work with common gTLDs, but some ccTLDs have a very annoying policy where they only allow one-year renewals and the renewal doesn't show up in the whois until the last moment.
Anyway, it's trivial to find out whether a domain was expired and re-registered. The date of initial registration in the whois will change, so you can just compare it with the value you saw when you first issued a certificate for that domain.
> ISRG may disclose Private Recovery Information, however, if compelled to do so by court order or other compulsory legal process. If possible, ISRG will give You notice of the potential disclosure and an opportunity to contest it.
this is what I expect, but then they also write
> ISRG may also disclose your PRI if it believes disclosure is necessary to prevent loss of life, personal injury, damage to property, or significant financial harm.
To me that sounds like an easy backdoor for corporate interests (significant financial harm) or law enforcement to bypass court orders. Isn't the legal process there in the first place to ensure that such claims are truthful?
Granted, PRI seems to be about email addresses and phone numbers [possibly more? the text says "such as"], but getting disposable phone numbers is not that easy in some countries.
In particular the "disclose ... if it believes ... financial harm" part seems a little weird.
Disclose to whom? To anybody?
"If it believes" – it's impossible to disprove that someone holds a certain belief. (Can a person who is a non-human corporation even hold beliefs?) Maybe this should say something about "reasonably expect" or something along those lines, something that can be argued about if there is disagreement?
As for financial harm, if I were to run a successful business on my domain, wouldn't my success in attracting customers be doing financial harm to my competitors?
One thing to emphasize about the PRI is that (perhaps differently from what you might be used to with some domain registrars or certificate authorities), the PRI is always optional for Let's Encrypt, and is used only in case of a problem such as losing your private key. You don't have to provide the PRI in order to get a cert, and this isn't a backdoor effort to require people to give a legal name in order to get a cert.
Having a working e-mail address is really valuable as a recovery mechanism -- but if you're very confident you won't need that and you don't want to give contact information, you need not do so.
> You Warrant to ISRG and the public-at-large that You have not participated in the seizure of a domain name that had ongoing lawful uses.
Is this meant to refer to the domain you're requesting, or does it literally mean that any person or organization that has ever participated in the seizure of any domain name that had ongoing lawful uses is banned? (For example, this would ban Microsoft, as well as arguably the entire U.S. government, from legally requesting certificates. The cases in question were a bit reprehensible, but it seems like an oddly specific requirement.)
...While this is of course standard for contracts, I also like the use of all caps and bold in the warranty disclaimer, which makes it extremely difficult to read, despite the U.C.C. clause that semi-not-really requires it being intended to ensure that signatories were aware of such terms! Let's Encrypt is a forward thinking organization; even if it's not terribly important, can't you take a stand against such absurdity and satisfy the conspicuousness requirement in a way that actually makes sense?
Definitions: “You” or “Your” — The organization and individual or individuals requesting, accepting, or using a Certificate issued by ISRG. It encompasses both the singular and the plural and is used in each instance both jointly and severally to concurrently refer to both natural persons as well as organizations and entities, regardless of the structure or form of such entity.
That would only appear to affect the FBI itself (i.e. if You == FBI), not individual employees of the FBI who were not involved in the seizure. But that could still be a lot of individuals (e.g. any secretary who shuffled papers involved in the seizure).
The bold caps are nearly unreadable. All caps is advocated against by many sources, like Typography for Lawyers (http://typographyforlawyers.com/all-caps.html), which specifically calls out bold caps. Even the Mozilla Public License abandoned all-caps for conspicuous text:
Bryan Garner, a noted expert on legal writing (and editor of Black's Law Dictionary), agrees:
> And the worst conventions in contracts?
> Caps for contract text that is required to be “conspicuous.” The 9th Circuit has rightly noted that “lawyers who think their caps-lock keys are instant ‘make conspicuous’ buttons are deluded.”
> For example, this would ban Microsoft, as well as arguably the entire U.S. government, from legally requesting certificates.
It would also prohibit many current and former employees of Microsoft and the U.S. government, and domain name registrars (both themselves, and current and former employees) whose participation was necessary to effect such seizures, even though they had no discretion in them, and law firms (both themselves, and current and former employees) involved in seizure, from getting certificates.
I also think the entire idea is unsound; the mere fact that a domain name had some ongoing lawful use shouldn't make seizing it a bad thing; I mean, if the primary use of it was for users exchanging, say, child pornography, but it also had a minor and incidental, but certainly ongoing, use for the same users to exchange perfectly lawful messages, is being involved -- even as a direct and primary actor -- in seizing the domain something which should result in an actor being punished by having a higher cost to participate in the emerging TLS-only internet community the way the Let's Encrypt policy suggests?
I don't see how the company's actions would affect the employees. If they directly participated in the seizure? Sure. But a random software developer at Microsoft, or a random CSR at the registrar shouldn't be affected by that clause.
The exclusion language in the agreement does not specify direct participation, merely participation.
But even the most direct participation is going to involve a large number of employees performing job functions as directed, and include firms (and employees at those firms) participating under a direct, non-discretionary legal mandate.
Sure, but you're not participating if your company participates, that's my point. An individual is separate from the company they work for. Microsoft as an entity can't request a certificate, sure. An employee that was involved in the seizure can't, sure, same deal. But an employee that had absolutely no involvement in the seizure but happens to work for the company? Nothing in that language says that they'd be banned.
I also highly doubt the scale you're talking about. I doubt that "many" employees are involved in a seizure. It's a sensitive matter, in the best interests of everyone to keep it as contained as possible.
> ISRG may modify this Agreement from time to time. Each modified
> version of this Agreement shall be posted to ISRG’s Let’s Encrypt
> website (letsencrypt.org) and shall be effective on the date
> specified on such website.
So what's in the agreement doesn't actually matter since it can be modified unilaterally at any time with a notice period of 0 milliseconds?
The idea here is that we need to be able to modify terms quickly if need be (e.g. if a critical issue is identified), but hopefully that will never be the case. Under normal circumstances we will post the updated agreement quite a while before it takes effect. Current thinking is that we'll try for 45-90 days.
The issue is that you are asking the user understand and agree to a legal contract, which they must then uphold, without giving similar guarantees on your end.
On my side, you want me to agree to do things and on your side "we'll try for 45-90 days." That's not good enough.
Ask your lawyer whether you want to include an express statement [1] that existing rights and obligations --- and, importantly, any dispute-resolution procedures --- will continue to be governed by the old agreement. That could be important in avoiding a court holding that the agreement is "illusory," and thus unenforceable, because of your power to change it at any time.
The problem with this approach is you're inflicting your legal liability on me.
A more appropriate way to deal with this would be to state that there will be a 30 day consultation period for every change, and if you do identify a "critical issue", to revoke every certificate and have everyone re-agree to it.
Now, I know you don't want to do that because if you do find a critical issue, solving it that way makes everyone mad at you, but here's the thing: that's how it works in every other business.
Withdrawing cars or software or nail polish or recommended finance strategies from use takes time, and if you make a critical fuckup then the methods for speeding up the withdrawal time are either non-existant or really piss people off.
It's a quirk of the legal system that you can "patch" these issues instantly, but you still have to unilaterally fuck people (at least in potentia) to do it.
The correct way to do it would be to take responsibility for the quality of your work and guarantee you won't change the agreement on people.
At the very least, you could state any changes will be binding for one week, and anyone who hasn't explicitly opted in to the new version after a week gets cut off until they do, but is released from that version.
My limited understanding is that Let's Encrypt's mission is to make encrypted web traffic available to as wide a population as possible. A six page legal agreement seems like an obstacle to that, especially if they want to serve that portion of the population who might not be accustomed to such things.
Keeping it short and simple would seem like a high priority; though perhaps this is as short and simple as it can reasonably get.
I encourage people to propose ways that it might be made shorter.
The CA/B Forum requires CAs to have legally-binding subscriber agreements covering the issuance of certificates. For example, check out section 9.6.1 of Baseline Requirements 1.3.0 ("CA Representations and Warranties").
They're definitely part of the problem, but they're a powerful kingmaker in the industry. Without their approval several vendors won't include the Let's Encrypt CA at all.
So it ultimately boils down to: Dance with the devil and become relevant, or maintain the moral high ground and accomplish nothing.
You've got things a little confused here. Let's Encrypt doesn't need to be part of the CABF in order to be included in the browsers, but they do need to demonstrate that they abide by the rules that CABF defines (the Baseline Requirements). They only need to join CABF if they want to be able to vote on those rules.
> Without their approval several vendors won't include the Let's Encrypt CA at all.
Which ones?
Let's Encrypt is Mozilla's baby IIRC, so this will almost certainly be recognized as valid by them with or without CAB membership, which means that Firefox and Firefox OS are both instantly covered. The former makes up a pretty sizable chunk of desktop user agents and (probably) a smaller but still significant chunk of mobile user agents (not including Firefox OS).
This leaves Google, Microsoft, Apple, the major GNU/Linux distro vendors (Red Hat, Canonical, SUSE/Novell), and maintainers of other operating system projects ((Open|Free|Net)BSD, Solaris/illumos folks (Oracle, Joyent, etc.), etc.).
* Google seems to be a proponent of ubiquitous encryption/HTTPS, and a free and easy-to-use CA aligns with that goal. I reckon they're more likely to support the Let's Encrypt CA than not for this reason, regardless of CAB membership. Thus, Chrome/Chromium, ChromeOS, and Android - the other significant chunk of desktop user agents, and arguably the most significant chunk of mobile user agents aside from feature phones (which will likely be phased out with low-cost Android and FirefoxOS devices anyway), will end up supporting Let's Encrypt's CA.
* Most GNU/Linux distros I'm aware of use Firefox as the default/primary browser in desktop deployments (the notable exception being Lubuntu last I checked), and many of them use Mozilla's cert bundle for their CA needs. I'd expect most other free software operating systems to follow suit.
* I'm not sure what Solaris uses as a default browser nowadays for desktop use (not that there are a whole lot of desktop Solaris users in the wild anymore...), but it's probably Firefox. Oracle tends to be more interested in bureaucratic institutions like the CAB, though, so they might hold off on Let's Encrypt for a long while (and thus further accelerating the effects of their sidaM touch on Solaris, but whatever). Most illumos-based operating systems (like OpenIndiana and SmartOS) will likely be more receptive to Let's Encrypt, though their desktop significance is also pretty low.
* This leaves Microsoft and Apple. On one hand, these particular vendors - like Oracle - tend to favor bureaucracy over common sense. On the other hand, Let's Encrypt probably wouldn't be the first non-CAB CA they've recognized as valid. On the third hand, it wouldn't be above Microsoft to spin off some "Visual Cert.NET 3.11# for Workgroups(TM)" as a competitor of sorts to draw folks toward Microsoft's sphere of influence (meanwhile, Apple would be no stranger to waiting for a few years before taking the trendy idea that everyone else is coming up with, calling it the "Apple Cert" with an Apple logo instead of the word "Apple", and insist that everyone calling it the "iCert" are ignoramuses while politely ignoring that - like their watches - they're about half a decade late to the game).
So - to summarize - two of the three most significant desktop browser vendors (Mozilla and Google), one of the two most significant smartphone browser/OS vendors (Google), and both of the two viable dumb->smart phone browser/OS vendors (Mozilla and Google) will in all likelihood recognize Let's Encrypt's validity regardless of whether or not it's a member of some random bureaucracy. That's a pretty substantial market driver.
You'll see that that's far from including all root or intermediate CAs that are active on the web.
But the major browsers have incorporated the Forum's standards directly or indirectly into their root certificate programs. If a CA doesn't comply with the standards, it will be harder for the CA (or its parent, if it's an intermediate) to be trusted by browsers.
Minor quibble, but I think the "Key Pair" heading of the Definitions section mixes up i.e. (id est, 'that is') and e.g. (exempli gratia, 'for example').
Digital signatures are one example of things you can do with a key pair, and it is specifically the public key that can't be used to recover the private key.
Man, there's a lot of references to the ACME client.
"The contents of Your Certificates will be based on the information You or Your ACME Client Software sends to ISRG."
"Your Key Pair (Public and Private Keys) will be generated by You or Your ACME Client Software on Your systems."
"Your ACME Client Software may perform this task for You."
"You may make a revocation request to ISRG using ACME Client Software."
"If you wish, You may configure Your ACME Client Software to notify You of such changes."
To be clear, ACME is a protocol. You don't need the ACME client to get a free ssl cert. You will be able to perform the steps needed with just openssl and curl. I hope this agreement doesn't get interpreted such that you must use the official ACME client to generate the ssl key and make the http requests.
There's references to your acme client - they don't specify the reference acme client. If you want to use curl or whatever else, that's your acme client
"1. Definitions and Terms
“ACME Client Software” — a software application that uses the ACME protocol to request, accept, use or manage Let’s Encrypt Certificates."
Did you have a lawyer who does this sort of work read this? I am not going to give you advice here since I'm not your lawyer, but you need to have one look at this. There are issues in this draft that need to be addressed.
The CA/Browser Forum Baseline Requirements require that the CA have you sign one:
"Prior to the issuance of a Certificate, the CA SHALL obtain ... either: 1. The Applicant’s agreement to the Subscriber Agreement with the CA, or 2. The Applicant’s agreement to the Terms of Use agreement."
Then I can't exactly support the "Let's Encrypt" effort. Any child should be able to make a website without having to sign a bunch of legalese. That's more important to me than encrypted traffic, frankly.
Argh, that is an awkward title. "Draft Subscriber Agreement for Let's Encrypt" would be clearer. Or even just adding quotes around "Let's Encrypt" would help.
There is probably a multi million dollar market in a well thought through tool for editing, commenting upon and finalising legal agreements... In fact I'd say online law tools for managing a whole firm in general could be an excellent business.
Perhaps it's time to supplement this legalese with an equivalent amount of explanatory language in layman's terms what your intent for these clauses is. You're starting to spook people because of what can be read into the legalese, and though your comments here seem to justify the clauses, that does not help other people that aren't reading this thread. Sort of like an app publisher explaining why they need such-and-such permission. I won't install some apps unless I have a pretty good explanation of why it needs certain permissions.
56 comments
[ 2.8 ms ] story [ 110 ms ] threadA few requirements:
- You have not participated in the seizure of a domain name that had ongoing lawful uses
- all information in Your Certificate regarding You or Your domain name is accurate, current, reliable, complete, and not misleading
- all information You have provided to ISRG is accurate, current, complete, reliable, complete, and not misleading
- You have taken all appropriate, reasonable, and necessary steps to secure and keep your Private Key secret
They can send you away even if you do everything they ask:
- ISRG may, in its sole discretion, refuse to grant Your request for a Let’s Encrypt Certificate, including for reasons not stated in this Agreement
- ISRG may also, without advanced notice, revoke Your Certificate if it determines, in its sole discretion, that … Your Certificate has become unreliable
- ISRG may also, without advanced notice, revoke Your Certificate if it determines, in its sole discretion, that … information in your registration with ISRG or request for an Let’s Encrypt Certificate has changed
I would. Especially if they refused to cooperate with the US gov't.
I'll say this, I don't want to see "Let's Encrypt" go on some moral crusade deciding not to grant a certificate to a website because that website contains offensive content, but their job is to verify at least somewhat the identity of the requester to try and stem impersonation.
But that's a registrar problem, not a "proof that this connection comes from someone who controls that domain" problem. These aren't EV certificates.
Otherwise https only gurantees that you're actually talking to the domain you see in the URL, not who that domain belongs to.
Also, seizure and hijacking aren't equivalent.
Anyway, it's trivial to find out whether a domain was expired and re-registered. The date of initial registration in the whois will change, so you can just compare it with the value you saw when you first issued a certificate for that domain.
> ISRG may disclose Private Recovery Information, however, if compelled to do so by court order or other compulsory legal process. If possible, ISRG will give You notice of the potential disclosure and an opportunity to contest it.
this is what I expect, but then they also write
> ISRG may also disclose your PRI if it believes disclosure is necessary to prevent loss of life, personal injury, damage to property, or significant financial harm.
To me that sounds like an easy backdoor for corporate interests (significant financial harm) or law enforcement to bypass court orders. Isn't the legal process there in the first place to ensure that such claims are truthful?
Granted, PRI seems to be about email addresses and phone numbers [possibly more? the text says "such as"], but getting disposable phone numbers is not that easy in some countries.
Disclose to whom? To anybody?
"If it believes" – it's impossible to disprove that someone holds a certain belief. (Can a person who is a non-human corporation even hold beliefs?) Maybe this should say something about "reasonably expect" or something along those lines, something that can be argued about if there is disagreement?
As for financial harm, if I were to run a successful business on my domain, wouldn't my success in attracting customers be doing financial harm to my competitors?
But, of course, IANAL!
One thing to emphasize about the PRI is that (perhaps differently from what you might be used to with some domain registrars or certificate authorities), the PRI is always optional for Let's Encrypt, and is used only in case of a problem such as losing your private key. You don't have to provide the PRI in order to get a cert, and this isn't a backdoor effort to require people to give a legal name in order to get a cert.
Having a working e-mail address is really valuable as a recovery mechanism -- but if you're very confident you won't need that and you don't want to give contact information, you need not do so.
Is this meant to refer to the domain you're requesting, or does it literally mean that any person or organization that has ever participated in the seizure of any domain name that had ongoing lawful uses is banned? (For example, this would ban Microsoft, as well as arguably the entire U.S. government, from legally requesting certificates. The cases in question were a bit reprehensible, but it seems like an oddly specific requirement.)
...While this is of course standard for contracts, I also like the use of all caps and bold in the warranty disclaimer, which makes it extremely difficult to read, despite the U.C.C. clause that semi-not-really requires it being intended to ensure that signatories were aware of such terms! Let's Encrypt is a forward thinking organization; even if it's not terribly important, can't you take a stand against such absurdity and satisfy the conspicuousness requirement in a way that actually makes sense?
Thanks for the feedback.
http://lu.is/blog/2012/08/19/a-quick-note-on-conspicuous-tex...
Bryan Garner, a noted expert on legal writing (and editor of Black's Law Dictionary), agrees:
> And the worst conventions in contracts?
> Caps for contract text that is required to be “conspicuous.” The 9th Circuit has rightly noted that “lawyers who think their caps-lock keys are instant ‘make conspicuous’ buttons are deluded.”
http://www.abajournal.com/magazine/article/4_vignettes_lead_...
It would also prohibit many current and former employees of Microsoft and the U.S. government, and domain name registrars (both themselves, and current and former employees) whose participation was necessary to effect such seizures, even though they had no discretion in them, and law firms (both themselves, and current and former employees) involved in seizure, from getting certificates.
I also think the entire idea is unsound; the mere fact that a domain name had some ongoing lawful use shouldn't make seizing it a bad thing; I mean, if the primary use of it was for users exchanging, say, child pornography, but it also had a minor and incidental, but certainly ongoing, use for the same users to exchange perfectly lawful messages, is being involved -- even as a direct and primary actor -- in seizing the domain something which should result in an actor being punished by having a higher cost to participate in the emerging TLS-only internet community the way the Let's Encrypt policy suggests?
The exclusion language in the agreement does not specify direct participation, merely participation.
But even the most direct participation is going to involve a large number of employees performing job functions as directed, and include firms (and employees at those firms) participating under a direct, non-discretionary legal mandate.
I also highly doubt the scale you're talking about. I doubt that "many" employees are involved in a seizure. It's a sensitive matter, in the best interests of everyone to keep it as contained as possible.
Thanks for your feedback.
On my side, you want me to agree to do things and on your side "we'll try for 45-90 days." That's not good enough.
[1] See, e.g., the clause and extensive annotations at http://www.commondraft.org/#AmendUnilateralCls (self-cite).
A more appropriate way to deal with this would be to state that there will be a 30 day consultation period for every change, and if you do identify a "critical issue", to revoke every certificate and have everyone re-agree to it.
Now, I know you don't want to do that because if you do find a critical issue, solving it that way makes everyone mad at you, but here's the thing: that's how it works in every other business.
Withdrawing cars or software or nail polish or recommended finance strategies from use takes time, and if you make a critical fuckup then the methods for speeding up the withdrawal time are either non-existant or really piss people off.
It's a quirk of the legal system that you can "patch" these issues instantly, but you still have to unilaterally fuck people (at least in potentia) to do it.
The correct way to do it would be to take responsibility for the quality of your work and guarantee you won't change the agreement on people.
At the very least, you could state any changes will be binding for one week, and anyone who hasn't explicitly opted in to the new version after a week gets cut off until they do, but is released from that version.
Keeping it short and simple would seem like a high priority; though perhaps this is as short and simple as it can reasonably get.
The CA/B Forum requires CAs to have legally-binding subscriber agreements covering the issuance of certificates. For example, check out section 9.6.1 of Baseline Requirements 1.3.0 ("CA Representations and Warranties").
https://cabforum.org/wp-content/uploads/CAB-Forum-BR-1.3.0.p...
So it ultimately boils down to: Dance with the devil and become relevant, or maintain the moral high ground and accomplish nothing.
Which ones?
Let's Encrypt is Mozilla's baby IIRC, so this will almost certainly be recognized as valid by them with or without CAB membership, which means that Firefox and Firefox OS are both instantly covered. The former makes up a pretty sizable chunk of desktop user agents and (probably) a smaller but still significant chunk of mobile user agents (not including Firefox OS).
This leaves Google, Microsoft, Apple, the major GNU/Linux distro vendors (Red Hat, Canonical, SUSE/Novell), and maintainers of other operating system projects ((Open|Free|Net)BSD, Solaris/illumos folks (Oracle, Joyent, etc.), etc.).
* Google seems to be a proponent of ubiquitous encryption/HTTPS, and a free and easy-to-use CA aligns with that goal. I reckon they're more likely to support the Let's Encrypt CA than not for this reason, regardless of CAB membership. Thus, Chrome/Chromium, ChromeOS, and Android - the other significant chunk of desktop user agents, and arguably the most significant chunk of mobile user agents aside from feature phones (which will likely be phased out with low-cost Android and FirefoxOS devices anyway), will end up supporting Let's Encrypt's CA.
* Most GNU/Linux distros I'm aware of use Firefox as the default/primary browser in desktop deployments (the notable exception being Lubuntu last I checked), and many of them use Mozilla's cert bundle for their CA needs. I'd expect most other free software operating systems to follow suit.
* I'm not sure what Solaris uses as a default browser nowadays for desktop use (not that there are a whole lot of desktop Solaris users in the wild anymore...), but it's probably Firefox. Oracle tends to be more interested in bureaucratic institutions like the CAB, though, so they might hold off on Let's Encrypt for a long while (and thus further accelerating the effects of their sidaM touch on Solaris, but whatever). Most illumos-based operating systems (like OpenIndiana and SmartOS) will likely be more receptive to Let's Encrypt, though their desktop significance is also pretty low.
* This leaves Microsoft and Apple. On one hand, these particular vendors - like Oracle - tend to favor bureaucracy over common sense. On the other hand, Let's Encrypt probably wouldn't be the first non-CAB CA they've recognized as valid. On the third hand, it wouldn't be above Microsoft to spin off some "Visual Cert.NET 3.11# for Workgroups(TM)" as a competitor of sorts to draw folks toward Microsoft's sphere of influence (meanwhile, Apple would be no stranger to waiting for a few years before taking the trendy idea that everyone else is coming up with, calling it the "Apple Cert" with an Apple logo instead of the word "Apple", and insist that everyone calling it the "iCert" are ignoramuses while politely ignoring that - like their watches - they're about half a decade late to the game).
So - to summarize - two of the three most significant desktop browser vendors (Mozilla and Google), one of the two most significant smartphone browser/OS vendors (Google), and both of the two viable dumb->smart phone browser/OS vendors (Mozilla and Google) will in all likelihood recognize Let's Encrypt's validity regardless of whether or not it's a member of some random bureaucracy. That's a pretty substantial market driver.
https://cabforum.org/members/
You'll see that that's far from including all root or intermediate CAs that are active on the web.
But the major browsers have incorporated the Forum's standards directly or indirectly into their root certificate programs. If a CA doesn't comply with the standards, it will be harder for the CA (or its parent, if it's an intermediate) to be trusted by browsers.
Digital signatures are one example of things you can do with a key pair, and it is specifically the public key that can't be used to recover the private key.
"The contents of Your Certificates will be based on the information You or Your ACME Client Software sends to ISRG."
"Your Key Pair (Public and Private Keys) will be generated by You or Your ACME Client Software on Your systems."
"Your ACME Client Software may perform this task for You."
"You may make a revocation request to ISRG using ACME Client Software."
"If you wish, You may configure Your ACME Client Software to notify You of such changes."
To be clear, ACME is a protocol. You don't need the ACME client to get a free ssl cert. You will be able to perform the steps needed with just openssl and curl. I hope this agreement doesn't get interpreted such that you must use the official ACME client to generate the ssl key and make the http requests.
Someone might even be willing to do it pro-bono.
"Prior to the issuance of a Certificate, the CA SHALL obtain ... either: 1. The Applicant’s agreement to the Subscriber Agreement with the CA, or 2. The Applicant’s agreement to the Terms of Use agreement."
https://cabforum.org/wp-content/uploads/CAB-Forum-BR-1.3.0.p...
"Use" needs to be defined, otherwise it catches end-users who visit the website.