<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 8, 2017 at 3:39 PM, Jeremy Rowley <span dir="ltr"><<a href="mailto:jeremy.rowley@digicert.com" target="_blank">jeremy.rowley@digicert.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div lang="EN-US" link="blue" vlink="purple"><div class="m_7717770439886878427WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Sort of. I’d say the CAs have several automated tools available and are continuously improving on them to fit various subscriber use cases, but we’re looking at delays in deployment as customers fit these tools into their work flows, network requirements, and provisioning obstacles. I think we’re on the path towards shorter validity periods, but trying to get most large customers to adopt auto-deployment for their infrastructure by May 2018 will be nearly impossible.</span></p></div></div></blockquote><div><br></div><div>But one year (and change) certs are useful precisely because they _don't_ require automatic deployment. That is, the premise is that an action once every 13 months (or even 5,000 or 10,000 of those, once every 13 months - or spread out over 13 months) is a humanly possible task that absolutely does not require automation.</div><div><br></div><div>Automation improves the experience, but it is not, say, a proposal for 3 month certs - a solution that is _only_ realistically practical with automation.</div><div><br></div><div>Perhaps that's the disagreement - that, much like TLS configuration, requiring to update a server once a year is not unreasonable. </div></div></div></div>