<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 6, 2017 at 9:52 PM, Scott Rea via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Perhaps the best thing we can do for the WebPKI community, is make it as<br>
simple and easy as possible to replace or upgrade existing certificates<br>
- then it matters less how long the existing cert was issued for,<br>
because if an issue arises that requires a current cert to be updated,<br>
then that becomes a simple process and no longer a barrier, so just<br>
replace it, and there is no need to wait until an expiration. By<br>
greasing the skids of cert replacement, a lot of the challenges<br>
discussed on this thread could be mitigated. So instead of heaping an<br>
ever increasing regulatory load on CAs, lets just encourage them to<br>
deploy simple easy replace strategies instead.<br></blockquote><div><br></div><div>While I absolutely agree that we (as an industry) can and should encourage more automation, and I'm encouraged that ACME adds yet another protocol to do so - but one that works well with the Internet (rather than the Enterprise PKI) - I'm not sure that it's sufficient to say that if we automate, we've solved the problems. I think that may be a core disconnect here.</div><div><br></div><div>The difference here is whether or not automation is forced; if automation isn't forced - that is, if we allow 39 month certs, but say you should replace them every 13 - then we know that a large number of customers won't do so, because there's no forcing function. As a consequence, no matter how much evangelism we make that "This change is coming and your existing certs won't work and you should replace them", if browsers make a change to enforce that requirement, they'll be the ones that take the blame when things break.</div><div><br></div><div>This is a principle we've encountered time and time again - my colleague Adam Langley has summarized this as "The most recent system to change is the system that will be blamed". That is, if browsers enforce something, the browsers will be blamed - as we see with any deprecations or enforcements (whether it be SHA-1 or validity periods or potentially things like EKUs or policy OIDs, as we saw with Microsoft's recent root program update). Similarly, a system that required CAs to revoke such 'old' certs (imagining a system where revocation works) simply shifts that blame to CAs - that is, the CAs get blamed by their customers for revoking the certs, and I don't think we want that either.</div><div><br></div><div>So this is where expiration shifts that balance, by reusing the existing set of systems and controls (namely, the need to periodically replace certificates). By shifting the 'burden of change' to the client, we shift the blame 'to the client'.</div><div><br></div><div>Now, I can fully understand the perspective of some CAs that reducing the validity AND imposing changes (e.g. via the Forum) sets them to be the point of blame - that is, whenever a customer then approaches for their new certificate, and the CA tells them "Sorry, this isn't allowed anymore," they'll be the ones blamed. But at some point, it's unavoidable that there's going to be blame. The benefit of shifting that relationship to the CA<->Subscriber (through the renewal process) rather than the current ecosystem of Browser<->Subscriber, we shift to a better communication medium and one that causes the least amount of harm and damage to Relying Parties - which I think is a shared goal of everyone here, or so I'd hope.</div></div></div></div>