[cabfpub] SHA-1 changes and certificate lifetimes

[Steve Roylance]

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