<div dir="ltr"><div class="gmail_extra">I'll try to simplify the replies, because it seems that giving a long list of reasons is causing too much confusion:</div><div class="gmail_extra"><br></div><div class="gmail_extra">1) Do you acknowledge and agree that a shorter-lived certificate makes for a natural revocation?</div><div class="gmail_extra">2) Do you acknowledge and agree that a shorter-lived certificate ensures that policies regarding new issuance can come in effect quicker than the current system?</div><div class="gmail_extra"><br></div><div class="gmail_extra">Your attempts to ignore the SHA-1 issue are surprising. I would have thought the data that Microsoft shared regarding their efforts to deprecate this - due to the security risk to their users - while minimizing impact - would have unquestionably shown why this was necessary. 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.</div><div class="gmail_extra"><br></div><div class="gmail_extra">The irony here of your objections to continuing the SHA-1 discussion is that, anticipating these problems, Google tried to help communicate to users and site operators the risk that CAs' repeated failures would cause, and the CA Security Council objected to this. So we have a situation where CAs are not actually trying to help the ecosystem (or their users) be more secure, we have ample evidence how the practice of long-lived certs prevents meaningful improvement, and CAs objecting to any and all efforts to improve the ecosystem to date that don't involve CRLs/OCSP, a set of unusable technologies in part due to CAs poisoning that well. That's not a healthy ecosystem.</div><div class="gmail_extra"><br></div></div>