> On Feb 3, 2017, at 3:00 PM, Ryan Sleevi via Public <[email protected]> > wrote: > > To recap and refresh - the significant challenge reported was due to the > long-lived nature of the certificates meaning that disabling SHA-1 - thus > protecting the ecosystem - would and did cause considerable impact.
Weren’t most of the long-lived certificates that caused problems those issued before the current limit of ~3 years? In particular: - A 10-year certificate issued right before the BRs were adopted would expire 30 June 2022 - A 5-year certificate issued when special circumstances were allowed, could expire 31 March 2020 - The no-SHA-1 requirement came into force January 2015, and may have been a little rushed (or, really, should have been done sooner so that the hurry wasn’t necessary) So it seems to me this point is addressing a problem that has already been mostly solved; there’s a big difference between waiting 7 years to do something, and being able to do it in 3 years. As we’ve seen, it appears that once you’re down to about 2 years, the limiting factor is not certificate expiry but getting the rest of the Internet to catch up. As for revocation, I believe it is a problem that can be solved, and even if it can't, it does not really motivate a reduction to 1 year; you would need to go to 1 week or similar. This is a much longer discussion than I can have here. That said, I would be interested in a reduction from ~3 years to ~2, unifying the BRs and the EV guidelines. It seems like the 2-year period in EV is something that certificate users can cope with, and it would eliminate a reason not to adopt EV. It would also have worked fine for the SHA-1 case.
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
