Every form of payment, no matter in which direction, needs to provide enough benefit to justify the costs of the complexity added by it.
The purpose of ISRG (the not-for-profit which runs Let's Encrypt) is to drive automated issuance for Web PKI certificates. Nothing about this directly means they should be free - surely a not-for-profit could deliver this as an at-cost service, so why zero cost when that's not a core goal?
Machines don't have wallets. If they charge even 1¢ for a Let's Encrypt certificate (which would certainly cover costs at current issuance rates) now there needs to be a payment flow, which the machine needs help with because it doesn't have money. At zero cost all of that goes away and leaves you only solving engineering problems to achieve your goal of automated issuance.
EDIT: fixed arithmetic, thanks skj
Or more precisely, it's good for the party operating at scale and bad for the individual participant. This is the opposite of how most financial schemes handle unpredictable events: they put the risk on the party that can absorb the risk by letting it be lost in the noise, and take it away from the party that cares deeply about small amounts. Insurance companies will charge everyone the same amount, whether it's a customer that will ultimately bring them a bit of revenue or ultimately cost them a lot of money: the price for the individual customer is fixed. A plane flight costs the same amount of money whether there are strong tailwinds and the plane flew cheaper than expected or whether there was bad enough weather that the flight had to land somewhere for refueling, and the cost of the occasional rare disruption is built into the ticket.
This trick is mathematically nice, but there isn't really a reason for a consumer to prefer it to even paying $.02, unless the consumer is also paying at scale (in which case you can just aggregate the transfer and not use this scheme at all).
This is only needed for micropayments so a buffer of like $5-10 could be fine if you could somehow otherwise otherwise verify the user / monetize the relationship. Best way I can think of that preserves privacy is to serve image only ads through the payment network in an appropriately boxed window every time you add a tip to the randomized micropayment scheme.
Maybe, someday, micropayments will be good.
And if the problem is that even simple payment complicates things, complicated (probabilistic maybe or maybe not) payment isn't going to make it better.
Names meaning mostly DNS names like news.ycombinator.com but also numeric names such as 1.1.1.1
The Baseline Requirements (the rules Certificate Authorities agreed to obey some years back now) currently provide 13 potential ways to verify domain ownership, but these ways are sometimes called the Ten Blessed Methods dating back to when Gervase Markham was alive and worked on the Web PKI.
Although some of the Ten Blessed Methods are specific to the web in practice, such as 3.2.2.4.6 which involves creating a document to be retrieved from a web site, others really aren't such as 3.2.2.4.7 which is just a DNS change. Let's Encrypt offers both these (as challenges http-01 and dns-01 respectively)
Method 3.2.2.4.12 is specifically for domain registrars in the sort of relationship you're talking about, and is used by some registrars which also have a CA business (such as Google) today I believe.
‡ It got this name because the Web is why this PKI exists. SSL was invented by the Netscape Corporation, whose Web browser is the ancestor of today's Firefox. Netscape's successor, the Mozilla Foundation and Mozilla Corporation continues to be the most visible and only public oversight for the Web PKI. Perhaps if instead some other group had secured the Network it would be named, say, the Usenet PKI, or the IRC PKI or the NetBSD PKI, but they didn't and it isn't.
What makes webpki unique (and correct me if I am wrong) is how responsibilities are separated such that domain ownership is established by a 3rd party (like ISRG) as opposed to by the domain registrar. Logically speaking, the party transfering or registering domain ownership (for a fee) would also issue you a certificate at the time of transfer/registration. The different approaches to verify ownership would not be needed if the more sane approach was taken to begin with.
As you know, DNS is a protocol sepatate from TLS or other protocols. As such, domain ownership/control validation should be contained within the domain name system (also, why dnssec,dane and other efforts are under way, but they don't address the root cause of the problem).
For method 3.2.2.4.12 (and thanks for informing me about this), my comment was that it should be mandatory (not optional) for registrars to issue DV certs.
While I appreciate the ISRG, there are cases where using letsencrypt is not practical ,that aside, one org controlling so much of the web goes against the very concept of having TLDs that are independent in purpose/function. It would be more architecturally sane if what the ISRG does now was instead done at least at the TLR level. (E.g.: .com's owners should issue certs that says site.com belongs to whoever has this cert)
For the impractical corner cases: let's say I need to run a non-web service like SMTP and I can't spin up a web server to validate the domain. Or let's say I need non-TLS x509 such as ipsec.
> let's say I need to run a non-web service like SMTP and I can't spin up a web server to validate the domain.
You should use Let's Encrypt's implementation of 3.2.2.4.7 which is the dns-01 challenge as I already mentioned. Or use another vendor's own implementation of 3.2.2.4.7 or any of the half a dozen or so non-web methods listed.
> Or let's say I need non-TLS x509 such as ipsec.
The Web PKI can't help you. Leaf certificates in the Web PKI contain an EKU 1.3.6.1.5.5.7.3.1 which says their purpose is TLS server authentication. There is no global public PKI for IPsec. Feel free to try to make your own, but I expect it will be an expensive and thankless task.
The central issue of a PKI is trust and domain name registrars are not on the whole very trustworthy. We're talking about the industry which invented Domain Front Running - the idea of waiting until a customer shows interest in a unique product (a domain name) and then buying it yourself so that they'll have to buy it from you at an inflated price.
I sympathise with the desire to build a parallel PKI baked into the DNS system, but the Web PKI is not that system and there's no practical way to mutate it into that system. If you believe DANE is the only way forward you should go help people make DANE work better, not argue against the Web PKI.
Issuing "a certificate" at time of domain registration greatly misses the point of Internet hierarchical naming by the way. While it would be technically possible for every domain to hold a single wildcard certificate and use flat naming (so news.america.ycombinator.com couldn't exist, it would need to be news-america.ycombinator.com) that's a terrible security choice. Necessarily where a service corresponds to one specific name the certificate and corresponding private key should be for that name only, and not a hierarchy of related names in order to mitigate risk.
To address your concern, clients will have TLD certs in their trust store. TLDs issue intermediate CA certs to registrars. When you get a domain, they issue a cert (not x509 neccesarily) that allows you to issue certificates like an intermediate but restricted to that domain and its subdomains. So news.america and news. Under ycombinator.com will have separate certs,signed by the owner of ycombiator.com which on turn has to have their CA cert signed by a registrar.
This actually can improve security, because you can isolate your intermediate signig key from the rest of your services, and possibly have a dynamic process of issuing extremely short lived certs by your CA box to all of your services. Code signing certs,s/mime,client certs, eap-tls,etc... Can all be more easy to use. For example, if I could use eap-tls to connect to wifi at an airport or starbucks using a cert I issued myself under my domain (or under my work/school domain). Things that have been notoriously hard to adopt like TLS client certs could easier to use because anyone can have a client cert issued to them by any domain owner (likely the domain of their email provider for most) because any site can verify their client cert using this system and anyone with a domain can issue certs. This is the natural and most sensible way.
As for trust, you already trust them with the power to transfer your domain. If someone compromises your registrar account, what stops them from taking over the domain,pointing it at their own servers and getting a new cert from ISRG? Imagine getting a government ID and to verify it's legitimacy,people have to contact 3rd party companies instead of the government, that makes no sense. Things are the way they are because public key crypto was not used widely when DNS and the internet became a thing.
How long does it take to mine 1¢ worth of bitcoin? Or, is there anything else a machine can do in a relatively short timeframe that’s worth 1¢ to someone else?
t2.micro instances on AWS rent for about 1¢/h...
The whole point of profitable mining is to build asics such that the cost of electricity gets lower than the mining rewards.
I don't think you can mine $0.01 worth of bitcoin. Most of the time, you'll lose the race to find the correct hash collision and so you'll end up with nothing. Other times, you'll win and get the reward for the block which is 12.5 BTC at the moment (IIRC). People do join collectives to pool their mining power, but there isn't predictability to when the collective will end up with a coin. If you're looking to set up a web server, you don't want to be waiting days or weeks or whatever while your collective tries to win a block. Theoretically, you could buy a lot of computing power and always get unlucky.
So you can't really get a penny of bitcoin via mining.
But mining once cent worth of bitcoin would cost you multiple dollars on a CPU.
Whether it's actual time spent signing up, putting in my credit card data, updating expired cards, etc. Or linking my account/PayPal/Venmo to receive tiny transactions.
Or just the friction of "do I really want to pay $0.05 for this?" And I just don't want to make a choice, so I close the tab.
I know a lot of people dream about microtransactions changing everything... but even if they work flawlessly technically, I just don't want the mental overhead of making 20 tiny economic decisions every time I use the internet. Ugh.
Decentralization is for clueless idiots who doesn't understand Decentralization or everything is a trade-off concept
LOL, that's so obvious in retrospect: if something costs so little, it's because you probably don't need it. Minor annoyances, even the mere decision, and you won't bother.
But note they mean zero price, not zero cost.