4 ms·

Why this high handed approach by the letsencrypt team? This completely arbitrary 90 day limit makes little sense when the world has been using 1 and 3 year cert

by throw2016 9y ago

Why this high handed approach by the letsencrypt team? This completely arbitrary 90 day limit makes little sense when the world has been using 1 and 3 year certs without issue. This seems to be very little justification for it apart from questionable security assumptions that will not stand up to scrutiny. Are they suggesting sites not using letsencrypt are insecure? Why make assumptions in the first place about day to day server security when you are in the business of issuing certificates? This just reflects a patronizing attitude that places constraints on others because of individual preferences. If they want to advocate 90 day renewals a more reasonable approach is a separate team to provide tools and advocate 90 days renewals.

pfg 9y ago
First, it's worth pointing out that certificate lifetime is tangential to HPKP. HPKP is public key-based, and nothing prevents you from using the same public key for years. > This completely arbitrary 90 day limit makes little sense when the world has been using 1 years, 3 year certs without issue. Browsers vendors (most notably Google and Mozilla) have been pushing for shorter certificate lifetimes for years. 3-year certificates have been banned starting with March 2018 (the new limit being something like 2 years and 2 months). Google itself has settled on 90-day certificates for most of their web properties, and they continue to push for shorter lifetimes in the CA/B Forum and might very well start enforcing it through their own root policy if no consensus is reached. > This seems to be very little justification for it apart from questionable security assumptions that will not stand up to scrutiny. Are they suggesting sites not using lets encrypt are insecure? [citation needed]. For a long discussion on the pros and cons, see [1]. > Why make assumptions in the first place about day to day server security when you are in the business of issuing certificates? One thing to keep in mind is that Let's Encrypt is in the business of creating a more secure and privacy-respecting Web. Naturally, it would be silly to focus solely on those two things if you actually want anyone to use your product, but if the cost of picking the more secure option isn't too high, I wouldn't expect them to go for the perhaps slightly easier option, especially given that automation is another one of their goals and the issues are mostly with manual processes. [1]: https://community.letsencrypt.org/t/pros-and-cons-of-90-day-certificate-lifetimes/4621?u=pfg https://community.letsencrypt.org/t/pros-and-cons-of-90-day-...
- apple4ever 9y ago
  > One thing to keep in mind is that Let's Encrypt is in the business of creating a more secure and privacy-respecting Web. And their required short certificates go against that philosophy. Allowing short ones is fine. Requiring it is dumb. And that discussion had very little good pros. I feel the short certificate discussion nicely mirrors the short password discussion- both short proponents have little good arguments on their site.
apple4ever 9y ago
Its absolutely mind boggling they REQUIRE 90 days. Offering is great, encouraging it is fine, but requiring it is dumb. It actually goes against their stated policy of encrypting the entire Internet, because it makes it so much harder or riskier to keep the certificate up to date (yes, even with automation).

pfg 9y ago

First, it's worth pointing out that certificate lifetime is tangential to HPKP. HPKP is public key-based, and nothing prevents you from using the same public key for years. > This completely arbitrary 90 day limit makes little sense when the world has been using 1 years, 3 year certs without issue. Browsers vendors (most notably Google and Mozilla) have been pushing for shorter certificate lifetimes for years. 3-year certificates have been banned starting with March 2018 (the new limit being something like 2 years and 2 months). Google itself has settled on 90-day certificates for most of their web properties, and they continue to push for shorter lifetimes in the CA/B Forum and might very well start enforcing it through their own root policy if no consensus is reached. > This seems to be very little justification for it apart from questionable security assumptions that will not stand up to scrutiny. Are they suggesting sites not using lets encrypt are insecure? [citation needed]. For a long discussion on the pros and cons, see [1]. > Why make assumptions in the first place about day to day server security when you are in the business of issuing certificates? One thing to keep in mind is that Let's Encrypt is in the business of creating a more secure and privacy-respecting Web. Naturally, it would be silly to focus solely on those two things if you actually want anyone to use your product, but if the cost of picking the more secure option isn't too high, I wouldn't expect them to go for the perhaps slightly easier option, especially given that automation is another one of their goals and the issues are mostly with manual processes. [1]: https://community.letsencrypt.org/t/pros-and-cons-of-90-day-certificate-lifetimes/4621?u=pfg https://community.letsencrypt.org/t/pros-and-cons-of-90-day-...

apple4ever 9y ago
> One thing to keep in mind is that Let's Encrypt is in the business of creating a more secure and privacy-respecting Web. And their required short certificates go against that philosophy. Allowing short ones is fine. Requiring it is dumb. And that discussion had very little good pros. I feel the short certificate discussion nicely mirrors the short password discussion- both short proponents have little good arguments on their site.

apple4ever 9y ago

Its absolutely mind boggling they REQUIRE 90 days. Offering is great, encouraging it is fine, but requiring it is dumb. It actually goes against their stated policy of encrypting the entire Internet, because it makes it so much harder or riskier to keep the certificate up to date (yes, even with automation).