<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 8, 2017 at 8:50 PM, Ryan Sleevi 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"><div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote"><span class="gmail-">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:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_6754274700704853685m_7717770439886878427WordSection1"><p class="MsoNormal"><span style="font-size:11pt;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></span></div></div></div></blockquote><div><br></div><div>I basically want to say something similar to Ryan's reply -- a 1-year limit on certificates should not be seen (by CAs or subscribers) as tantamount to a requirement to adopt auto-deployment for their infrastructure. Manual rotation every year is reasonable, and I've seen lots of individuals and enterprises do exactly that.</div><div><br></div><div>I also highly doubt that the 56% of the Alexa Top 1000 that use certs with 13-month-or-less timelines are all automating their cert renewal. </div><div><br></div><div>1 year is within the tolerance zone for manual rotation.  But if it starts adding some friction at scale to huge enterprises with many thousands of manually deployed certificates, that they're used to rotating every 2-3 years, well, that is the intended (positive) effect.</div><div><br></div><div>-- Eric</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="gmail-"><div><br></div></span><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>
<br>______________________________<wbr>_________________<br>
Public mailing list<br>
<a href="mailto:Public@cabforum.org">Public@cabforum.org</a><br>
<a href="https://cabforum.org/mailman/listinfo/public" rel="noreferrer" target="_blank">https://cabforum.org/mailman/<wbr>listinfo/public</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><a href="https://konklone.com" target="_blank">konklone.com</a> | <a href="https://twitter.com/konklone" target="_blank">@konklone</a><br></div></div></div></div></div></div></div>
</div></div>