[cabfpub] Ballot 111 - Accelerate Max Certificate Lifetime Reduction Timetable

[kirk_hall at trendmicro.com]

I don’t agree that the existence of 60 month certs has delayed improvements to the SSL ecosystem – I don’t remember it ever coming up except when we drafted BR 9.2.1 itself setting a sunset date for issuance of 60 month certs at Nov. 1, 2015 (as I recall, this was at the suggestion of PayPay).   Can you cite any other examples where 60 month certs delayed an improvement?

Certainly the existence of 60 month certs has not prevented Microsoft from deprecating SHA1 as of Jan. 1, 2017, which will kill all SHA1 60 month certs issued since Jan. 1, 2012.

And if the existence of 60 month certs limits our ability to implement improvements – isn’t the same true for 39 month certs?  Extending that logic, why not reduce maximum certificate duration to 13 months so we can implement changes quickly?

In many cases, the transition periods we adopt are not just for the convenience of the CAs, but also for their customers who may have legacy systems that depend on the previous product.  As others have said, when there is a clear security need, we should not hesitate to implement new requirements quickly, even immediately, regardless of the effect on issued certs.  That condition is not present here.

Along with improving our industry, we should also aim for stability of the rules so we are not reversing prior decisions on short notice without good reason.  We are more likely to get uniform compliance that way.

Having said this, if the CAs that issue 60 month certs are happy with shortening the current end date of BR 9.2.1 to an earlier date (whether or not it coincides with the deprecation date for SHA1), we don’t object.  But in my opinion, we should not get into the habit of abrupt rule changes without a clear need.

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Jeremy Rowley
Sent: Friday, November 29, 2013 12:35 AM
To: 'CABFPub'
Subject: Re: [cabfpub] Ballot 111 - Accelerate Max Certificate Lifetime Reduction Timetable

60 month certs have limited the Forum’s ability to create improvements ever since we starting discussing the BRs, and practically every significant change we make includes a discussion about what do to accommodate long-lived certs. Several the results of these discussions, and barrier to change, are evident in the BRs themselves (issuance from a root, the internal server name deprecation date, etc). By eliminating long lived certs, the Forum eliminates one of the major obstacles in improving the industry, permitting the Forum to become the primary proponent for improvements instead of the browsers (ie, instead of Microsoft announcing that SHA2 is required for all certs three years from now, the Forum could have passed a BR requirement to the same effect).

Plus, the code signing working group focuses heavily on private key protection.  During the discussions, the group estimated that 50% of the problem certificates resulted from stolen or compromised private keys.  I imagine the problem is just as bad for SSL.  Add on top of that the fact that five-year old information is extremely stale and has likely changed.

Jeremy

From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of kirk_hall at trendmicro.com
Sent: Thursday, November 28, 2013 7:07 PM
To: Eddy Nigg (StartCom Ltd.); CABFPub
Subject: Re: [cabfpub] Ballot 111 - Accelerate Max Certificate Lifetime Reduction Timetable

Well, so far the existence of 60 month certs has not stopped the browsers from imposing new requirements on CAs and certificates that have an immediate effect on all certs (60 month and 39 month certs alike) – some browsers have even taken the position that new rules in the BRs adopted in July 2012 and made effective in February 2013 would apply *retroactively* to certs issued *before* those dates.

So I don’t really think it’s true that the existence of 60 month certs issued by some CAs has ever limited changes made by the Forum, or their effective dates.  Has it?

From: public-bounces at cabforum.org<mailto:public-bounces at cabforum.org> [mailto:public-bounces at cabforum.org] On Behalf Of Eddy Nigg (StartCom Ltd.)
Sent: Thursday, November 28, 2013 3:22 PM
To: CABFPub
Subject: Re: [cabfpub] Ballot 111 - Accelerate Max Certificate Lifetime Reduction Timetable


On 11/28/2013 10:53 PM, From kirk_hall at trendmicro.com:<mailto:kirk_hall at trendmicro.com:>
Are there any known security breaches from past-issued 60 month certs (such as someone stealing the private key plus using the cert beyond a 39 month expiration period, someone selling an old server that had a private key plus 60-month cert on it, change of corporate identity during a five-year period that rendered a properly-issued 60-month cert inaccurate, but the cert was still used, etc.)?  Or is the concern more theoretical?

Kirk, if you read the responses from Bruce and Dean (and maybe some others) you understand that every time a change needs to be introduced you'll get opposition from exactly those CAs that issue long-living certificates. We all understand that CAs want to nail a customer for as long as possible and make a difference by issuing certificates for long periods of time (irresponsible) because others won't do that - but since this requirement would be applied across the board I believe there will be no competitive disadvantage to any of them.

However the entire industry will improve once changes can be pushed through within ~ 3 years than currently 5 and previously 10. Being able to act faster and get rid of possible problematic certificates within the time-frame of 3 years without the need of revocation (which would result in a another outcry anyway) is probably a worthy goal. With the current upcoming changes it appears to be a golden opportunity to achieve that.
Regards



Signer:

Eddy Nigg, COO/CTO



StartCom Ltd.<http://www.startcom.org>

XMPP:

startcom at startcom.org<xmpp:startcom at startcom.org>

Blog:

Join the Revolution!<http://blog.startcom.org>

Twitter:

Follow Me<http://twitter.com/eddy_nigg>







TREND MICRO EMAIL NOTICE

The information contained in this email and any attachments is confidential

and may be subject to copyright or other intellectual property protection.

If you are not the intended recipient, you are not authorized to use or

disclose this information, and we request that you notify us by reply mail or

telephone and delete the original message from your mail system.




<table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential 
and may be subject to copyright or other intellectual property protection. 
If you are not the intended recipient, you are not authorized to use or 
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20131129/88f54ee6/attachment-0003.html>