[cabfpub] BR Rekey Rules

Wayne Thayer wthayer at godaddy.com
Thu Apr 17 15:35:50 UTC 2014

Correct, in my mind this has nothing to do with perpetuating long-lived certs, and I thought the EV language made that clear:

The expiration date of the replacement certificate is the same as the expiration date of the currently valid EV Certificate

-----Original Message-----
From: kirk_hall at trendmicro.com [mailto:kirk_hall at trendmicro.com] 
Sent: Thursday, April 17, 2014 7:12 AM
To: Gervase Markham; Wayne Thayer; CABFPub
Subject: RE: [cabfpub] BR Rekey Rules

Gerv -- I think Wayne is asking for a reissue rule for all certs (including 2 year and 3 year certs) that allows reissue to the original expiration date without having to re-vet the applicant.  For example, a customer might have been vetted on 1/1/2010 (good for 39 months) and receive a 3 year OV cert on 10/1/2012 that expires 9/30/2015.  The customer wants to revoke and reissue with a new cert that also expires on 9/30/2015.  The CA wants to do this, but the last vetting was more than 39 months ago.  

In my view, there is no need for revetting of identity for this customer just for the purpose of issuing a replacement cert (good for only 15 months) that expires when the original, valid, 3 year cert expired.  Requiring revetting in this case will slow down the ability of customers to deal with Heartbleed quickly.  This is not really about long-life certs in most cases.

We allow reissue to the original expiration date without revetting for EV -- why not for OV?

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Gervase Markham
Sent: Thursday, April 17, 2014 9:49 AM
To: Wayne Thayer; CABFPub
Subject: Re: [cabfpub] BR Rekey Rules

Hi Wayne,

On 12/04/14 01:17, Wayne Thayer wrote:
> Is there any support from other CAs and browsers to reconsider this BR 
> rule in light of the current situation, or to at least make an 
> exception for a major security event?

Long-life certs cause problems in the SSL ecosystem, because they delay the time that browsers and others can rely on a particular rule or innovation which began on date X applying to all certificates. We've been trying to reduce the maximum cert lifetime for a long time, including some creative ideas to leverage the SHA1pocalypse, but those ideas have been rebuffed. We are all still stuck waiting for the 2015 deadline which was agreed many moons ago.

Up to now, long-life certs haven't caused particular problems for CAs or individual sites which use them. But now that long-life certs are causing such problems for you and your customers, you want an exception made so that they don't. I'm afraid my initial reaction is somewhat unsympathetic. :-| If Heartbleed leads to a load of sites whose certs weren't BR-compliant now using certs which are, I am not going to be crying into my beer.

The max lifetime of an EV cert is 39 months, so the EV guidelines exception you mention wouldn't help if it were transported to the BRs with the same attendant restrictions. Transporting it to the BRs without also bringing the 39-month limit along is not actually making them match, it's putting a loophole in the BRs.

Public mailing list
Public at cabforum.org
<table class="TM_EMAIL_NOTICE"><tr><td><pre>
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.

More information about the Public mailing list