[cabfpub] SHA-1 changes and certificate lifetimes

[Tom Albertson]

Let me amend the question as though you were asking Windows, ex.

[Windows XP SP3]  was the first [Windows] version to support SHA256 [for SSL - see for details http://blogs.technet.com/b/pki/archive/2010/09/30/sha2-and-windows.aspx  and http://blogs.technet.com/b/pki/archive/2011/02/08/common-questions-about-sha2-and-windows.aspx ], but what is the %age
of previous versions still in use?  1%, 0.1%, 0.01% etc    

Regardless of the percentages of Windows XP Service Pack 2 (which has already fallen off of support) and Service Pack 3 (which will fall off support April 2014), both operating system versions will be off extended support well before the SHA2 deadlines posted.  Microsoft will stop accepting SHA1 SSL certificates on supported version of Windows by 1 January 2017, and SHA2 code signing certificates without timestamps by 1 January 2016.
	
Please help us educate your customers of these facts. If you see a significant number of customers having problems with SHA2 support as Inaba-san reported to us for Japanese feature phones in Ankara, then please let us know.
	
All the best,
Tom

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Steve Roylance
Sent: Saturday, November 16, 2013 2:49 AM
To: Geoff Keating
Cc: CABFPub
Subject: Re: [cabfpub] SHA-1 changes and certificate lifetimes

Hi Geoff (all)

This mail is sent to Geoff in part response to this thread, but actually goes to all the Browsers, especially Tom following the SHA2 announcement from Microsoft.

As you¹ve all seen, the SSL Product Management team in GlobalSign
(Katsuo-san) do back the suggestion to move to 3 year certificates (39 months to be precise so Rob¹s happy) and we¹d love to be able to push people to SHA256 by default, however, we also understand for initial discussions with key customers that they are also hesitant to change due to the lack of information on which browser versions (and operating systems, both desktop and mobile) actually support SHA256.

We know that we¹ll have problems in Japan (As Inaba-san highlighted in the last CABForum F2F session) and we know from studies that there will be problems in places like India and China that still favour older operating systems and less advanced technology, however, it would be great that the industry had a common message for SHA256 support.

So as an example question for Geoff, but hoping the others will chime in.

Mac OSX 1.5 was the first version to support SHA256, but what is the %age
of previous versions still in use?  1%, 0.1%, 0.01% etc   In fact do you
have something similar to this on Android adoption that all CAs can use to assure their subscribers that relying party issues will be minor?
http://en.wikipedia.org/wiki/Android_version_history

Thanks for anything you can do to assist our marketing teams.

Kind Regards
 
Steve Roylance
Business Development Director


P.S. Bruce¹s page is a good start but having the ability to back this up with %ages and official figures would be wonderful.
http://www.entrust.com/should-you-use-sha-2/





On 13/11/2013 20:14, "Geoff Keating" <geoffk at apple.com> wrote:

>
>On 13 Nov 2013, at 11:30 am, Wayne Thayer <wthayer at godaddy.com> wrote:
>
>> Hi Gerv,
>> 
>> On 13/11/13 10:59, Gervase Markham wrote:
>>>> I'm a bit surprised by this and don't see the relationship between  
>>>>this proposal and the new SHA-2 requirements. It is a fact that most  
>>>>all certs will have to be replaced in the next 3 years, but why does  
>>>>that imply that they need to be replaced with stronger certs that 
>>>>also  expire in no more than 3 years?
>>> 
>>> It is already the CAB Forum's stated intention to move the maximum 
>>>issuance lifetime to 39 months. However, due to (if I remember
>>> correctly) concerns about outstanding legacy certs, and that some 
>>>CAs might be unduly penalised as they were greater users of 
>>>longer-life certs than others, it was not thought possible to make 
>>>>such a change immediately. So, some time ago, we set the date as April 2015.
>>> 
>>> Now, however, there is no unlevel playing field or outstanding 
>>>long-lived legacy base because all (or almost all) existing certs now 
>>>have an effective lifetime of just over 3 years. So it seems a good
>>>>opportunity to move the already-agreed deadline to match the /de 
>>>>facto/ deadline.
>> 
>> There will still be the same "long-lived legacy base" of certificates 
>>until they are replaced with SHA-2 sometime between now and Jan 1, 2017.
>> This proposal doesn't force these to be replaced with shorter 
>>duration certificates.
>> 
>> I still don't understand how this proposal is connected to the new
>>SHA-2 rules.  Maybe the concern is that CAs will "upsell" customers to 
>>a new cert when replacing their existing SHA-1 certs, thus inflating 
>>the number of 4 & 5 year certs issued over the next year?
>
>Part of the motivation for the original lax deadline was that it didn't 
>really help to immediately shorten the duration to 3 years, because 
>there were certificates that were already existing and had a 10-year 
>duration, so it would take 7 years to get to the point where all 
>certificates had a
>3 year remaining duration.  However all or almost all of those (I'll 
>check and see if I can find a single SHA-2 cert with an expiry past 
>2018) will need to be revoked by 2017.
>
>So the result is:
>
>10-year cert issued on the BR effective date: would have expired July 
>2022, but now disallowed starting January 2017
>5-year SHA-2 cert issued today: expires February 2019   [note it's really
>5 years + 3 months]
>5-year SHA-2 cert issued April 2015: expires July 2020 3-year SHA-2 
>cert issued April 2015: expires July 2018
>
>So, at the moment, we won't be able to get to the point where all 
>certificates have a 3 year or less remaining duration until April 2017, 
>but those certificates haven't been issued yet, so if we bring the 
>3-year transition date forward then we can shorten this time.  I'd 
>suggest April 2014, though, not 'immediate', to give CAs time to 
>adjust; that would mean all certificates have a 3 year or less 
>remaining duration in April 2016.
>
>> In addition, reducing the allowed lifetime actually makes it harder 
>> to transition longer duration certs to SHA-2.  If a CA issues a 5 
>> year SHA-1 cert today and then can't reissue it with SHA-2 for the 
>> full term starting on Jan 1, then perhaps the least bad choice is to 
>> wait until the remaining lifetime of the cert is less than 39 months.
>
>
>This problem will occur with pre-BR 10-year certs anyway, some of those 
>can't be reissued for their original term at any time before they stop 
>working._______________________________________________
>Public mailing list
>Public at cabforum.org
>https://cabforum.org/mailman/listinfo/public


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