[cabfpub] SHA-1 changes and certificate lifetimes

[Rob Stradling]

On 13/11/13 10:26, Gervase Markham wrote:
<snip>
> 2) Do we say 36 months, or 39? I cannot remember what the arguments are
> for 39 months over 36, so perhaps those who made them would care to
> review them for us. I think "3 years" is easy to understand, and fits
> with the MS dates well, given that we are now in mid-November.

When a customer renews an SSL certificate, it's common practice to set 
the "notBefore" date of the new cert to today, and the "notAfter" date 
to precisely N years after the old cert expires.  So if a customer 
renews a 3yr cert 3 months before expiry, the new cert will be valid for 
39 months.

Reducing the maximum validity period to 36 months would mean that the 
validity periods of the old 3yr cert and new 3yr cert cannot overlap. 
Or, if they do overlap, the customer would have to accept that they're 
paying for some number of days twice.  Or, the CA would have to issue a 
27month cert now; then, 27 months later, issue a 9month cert.  Or, the 
CA could scrap their 3yr cert product and sell a 33month cert product 
instead.

Basically, a maximum of 39 months makes renewing 3yr certs practical.

> 3) I am curious as to whether any CAs are actually needing to take
> advantage of the "continuing issuance exception" in the latter part of
> section 9.4.1. It requires a system that "fails to operate if the
> Validity Period is shorter than 60 months". My gut tells me that there
> must be very few systems like that indeed. Does anyone have information
> to report on this question?

And if there are any such legacy systems, do they also fail to operate 
if the signature hash algorithm is not SHA-1 (or MD5 or MD2) ?

-- 
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online