[cabfpub] Draft Ballot 185 (2) - Limiting the Lifetime of Certificates

[Jeremy Rowley]

Manual rotation is reasonable for these enterprises at 3 years. With 30,000 certs spread over multiple organizations, manual rotation in one year increments is not yet feasible, although they are working towards automation. Again, I do not think the 56% number is accurate. I would like to see more information on how this data was gathered as I suspect it came from only evaluating the primary website of each of these organizations rather than the distribution of certificate lifecycles thoughout the organization’s infrastructure. Our initial internal evaluation shows the average lifecycle at two years when looking at the certificates from an organization perspective. I should have more data shortly.  

 

From: Eric Mill [mailto:eric at konklone.com] 
Sent: Wednesday, February 8, 2017 8:58 PM
To: CA/Browser Forum Public Discussion List <public at cabforum.org>
Cc: Jeremy Rowley <jeremy.rowley at digicert.com>; Ryan Sleevi <sleevi at google.com>
Subject: Re: [cabfpub] Draft Ballot 185 (2) - Limiting the Lifetime of Certificates

 

 

 

On Wed, Feb 8, 2017 at 8:50 PM, Ryan Sleevi via Public <public at cabforum.org <mailto:public at cabforum.org> > wrote:

 

 

On Wed, Feb 8, 2017 at 3:39 PM, Jeremy Rowley <jeremy.rowley at digicert.com <mailto:jeremy.rowley at digicert.com> > wrote:

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.

 

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.

 

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. 

 

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.

 

-- Eric

 

 

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.

 

Automation improves the experience, but it is not, say, a proposal for 3 month certs - a solution that is _only_ realistically practical with automation.

 

Perhaps that's the disagreement - that, much like TLS configuration, requiring to update a server once a year is not unreasonable. 


_______________________________________________
Public mailing list
Public at cabforum.org <mailto:Public at cabforum.org> 
https://cabforum.org/mailman/listinfo/public





 

-- 

konklone.com <https://konklone.com>  | @konklone <https://twitter.com/konklone> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/public/attachments/20170209/b53458aa/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4964 bytes
Desc: not available
URL: <http://cabforum.org/pipermail/public/attachments/20170209/b53458aa/attachment.bin>