I'm suuuper excited for this to launch! However, it's worrisome that the ACME protocol (what Let's Encrypt uses) still has a ton of bugs open[1] and they are still changing the protocol often. Just search for "TODO" on the spec markdown[2].
I want this project to proceed, but they should really focus on getting a much more mature and stable spec before launch. This isn't WebRTC, where you can just continuously tack on additional stuff or change the API constantly. It's TLS certs. The certs issued using this API end up telling people it's safe to input their passwords or credit card numbers.
I really hope the ACME spec gets stable before the launch in July.
> The certs issued using this API end up telling people it's safe to input their passwords or credit card numbers.
I'm pretty sure they shouldn't tell users it's safe to type in credit card numbers -- these certs are "domain validation" (DV).
The certs that generate a green chip in the address bar are "extended validation" (EV) certs that typically cost hundreds and require a human to manually verify things.
It's taken me years, but I've finally trained my Mom to "look for the lock" whenever she has to type her password or credit card in anywhere. I consider that a win. Trying to get her to understand more than "lock=safe, no lock=unsafe" is incredibly difficult that will take many more years. Like it or not, since DV has a lock, that's what the standard is for what's safe to people who don't understand there's multiple levels of security in computers.
Validation has nothing to do with the security of the certificate. There is nothing preventing you from using a DV, OV, or EV certificate to transmit any type of data you want.
> Validation has nothing to do with the security of the certificate.
It has to do with the security and accountability of the end-to-end process in which the certificate is used, which is a security concern even if you define "security of the certificate" so narrowly that it isn't relevant to the security of the certificate as such. (Though what you have a trusted third-party vouching for in the certificate -- which is the key distinction in EV -- is, I would think, by any reasonable standard, a factor in the security provided by the certificate.)
Yes, it is true that validation does add accountability and security. However, suggesting that DV certificates are less suitable than EV certificates for handling a certain kind of data is nothing more than misinformation.
The cipher being used and the SSL configuration dictate MUCH more about the security of a site than its level of validation. EV certificates do not guarantee the site isnt using a insecure cipher. EV certificates do not guarantee that the private key was not sent via plain text in an email while a network admin was installing it. So from an encryption standpoint, there is no advantage.
From a authentication standpoint, an EV MAY provide more security but remember: An EV primarily validates the name and location of the relying party. It does not check to see if they are operating ethically or if you are getting ripped off.
I dont think EV is bad, but clamping down on what type of certificates can be used gets tricky. There are very few uses where EV (or OV) certificates should be required.
I want this project to proceed, but they should really focus on getting a much more mature and stable spec before launch. This isn't WebRTC, where you can just continuously tack on additional stuff or change the API constantly. It's TLS certs. The certs issued using this API end up telling people it's safe to input their passwords or credit card numbers.
I really hope the ACME spec gets stable before the launch in July.
[1]: https://github.com/letsencrypt/acme-spec/issues
[2]: https://github.com/letsencrypt/acme-spec/blob/master/draft-b...