[cabfpub] Concerns regarding Mozilla Root Program/Baseline Requirements

Steve Roylance steve.roylance at globalsign.com
Thu Aug 1 20:00:57 UTC 2013

As I mentioned in my previous post we do need to solve this issue as the 60 month to 39 month transition will involve more CAs in the re-issuance logic problems as more CAs offer 5 year certificates today than offered greater than 5 year certificates prior to the BRs coming into force.

In fact, tracking back from April 2015 where it changes from 60 months to 39 months means 21 months before this date we need to ensure customers are informed they can't reissue if the NotAfter date is beyond July 2018. 

Whoops too late already for 5 year certificates.

So actually I agree with Ryan that we can't wait until September to solve this as more customers will have issues the longer we wait.

Sent from my iPhone

On 1 Aug 2013, at 20:34, "Rich Smith" <richard.smith at comodo.com> wrote:

>> -----Original Message-----
>> From: Gervase Markham [mailto:gerv at mozilla.org]
>> Sent: Thursday, August 01, 2013 3:20 PM
>> On 01/08/13 19:46, Rich Smith wrote:
>>> I have no problem with any of the above.  I can't speak to any other
>>> CAs practices around something like this, but as for Comodo, if a
>>> replacement is done on any certificate regardless of the term of
>>> validity, we re-verify domain control as per the BR.  We have done
>>> this even before the BR became effective.  We also require that the
>>> reissuance/re-key be based upon a CSR meeting current key size
>>> requirements (2048 on our system at this point) regardless of what
>> was allowed when the cert was originally issued.
>> If you are happy to update other facets of the cert to be BR-compliant,
>> why not the validity period? Is it just that it's a commercial PITA, or
>> is there another reason?
> [RWS] No other reason, commercial PITA pretty well sums it up.  For obvious 
> reasons, I prefer to avoid having customers scream at me if at all possible. 
> I'll take it and try to talk them down if it's for a good reason (or even for 
> a bad one), that's part of the job description, but this particular case just 
> strikes me as a zero sum gain for everyone involved.
>>> So, like I said, I don't really have enough certs out there to put up
>>> strong resistance to your reasoning and conclusion, but the fact is
>>> that if even one of these gets re-issued, the customer is going to
>>> scream bloody murder when I cut time off it and I'm going to have to
>>> talk them down and jump through hoops on our system to either get a
>>> partial refund issued or somehow tack another free cert on at the end
>>> of the BR allowed term (5 years from now).  Both of those things are
>> a
>>> bloody pain in the neck for what I see as zero added benefit to
>> anyone, so I'd really rather not have to deal with it.
>> The benefit of having a fixed time period of X years is that if we
>> outlaw a practice, we are able to confidently say X years later that
>> there are no more valid certs which have that problem. I'd like X to be
>> shorter than 5 years - that seems a long time to get rid of bad things
>> - but 5 years is what we ended up with after negotiation.
>> I feel your pain in the above - I realise that whatever solution is
>> implemented, it's going to require effort and/or code. Perhaps we
>> should go together to talk to the guy who thought SSL certs with a 10-
>> year validity period were a good idea, and clue him in :-)
>> Gerv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4041 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20130801/f57e75fc/attachment-0001.p7s>

More information about the Public mailing list