I can give a bit more information about our current thinking, though nothing has been decided yet.
Our current API endpoint offers only 90-day certificates, no option for longer or shorter. It’s very unlikely that we will change the lifetime or offer more options on this API endpoint.
At some point, ideally in 2017, we’ll introduce a new API endpoint which implements the final IETF ACME spec. It will initially run alongside our original API endpoint. This new API endpoint will likely have a shorter maximum (default) certificate lifetime. We haven’t decided how much shorter the max/default will be, but it will likely be incremental in nature rather than something drastic. I suspect we will initially just shorten the max/default lifetime and add an option for shorter variable lifetimes later on.
At some point we will retired the original API endpoint and all subscribers will have to use the new API endpoint. I suspect this won’t happen until at least a year after the new API endpoint is available.
Things we take into consideration when considering lifetimes:
Do people have the tools they need? The ACME clients out there are getting better and more numerous every day. Their automation support is getting better. Once a tool is good at automating renewal then it doesn’t matter much how often certificates are renewed – up to a point, at least. The better the client ecosystem is the more comfortable we get with shorter lifetimes.
Can we handle the load? We have to make sure we’re ready for any additional load that shorter lifetimes will create.
Regarding whether or not to offer optional shorter lifetimes than the default, there would be some work involved on our side to implement the option and associated policy, and we’d sacrifice the convenience of being able to assume that every certificate has exactly the same lifetime (as of right now, afaik, every single certificate we’ve ever issued, no exceptions, has a 90 day lifetime).