[cabfpub] Concerns regarding Mozilla Root Program/Baseline Requirements

[Rich Smith]

I suspect, as Steve has pointed out, the addition of the 60 vs. 39 month
question adds a few more dogs to this fight.  I'd like to propose something
like this as an addition to Section 9.4:

Certificates issued prior to the effective date of this document having a
validity period greater than 60 months, AND; Certificates issued prior to 1
April 2015, having a validity period greater than 39 months; MAY be
Reissued/Re-keyed with a validity period exceeding these requirements but
not to exceed the Valid To date of the originally issued certificate,
provided that the re-issued/re-keyed certificate is otherwise in full
compliance with all other technical and verification requirements contained
in this document.

Probably could use some word-smithing, but I think that strikes a good
balance between allowing CAs to continue to meet their commercial
requirements while still being able to move things forward regarding any
technical and verification requirements imposed by the BRs currently and in
future versions.  Thoughts?

-Rich

> -----Original Message-----
> From: Steve Roylance [mailto:steve.roylance at globalsign.com]
> Sent: Thursday, August 01, 2013 4:01 PM
> To: <richard.smith at comodo.com>
> Cc: Gervase Markham; Ryan Sleevi; CABFPub
> Subject: Re: [cabfpub] Concerns regarding Mozilla Root Program/Baseline
> Requirements
> 
> 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/x-pkcs7-signature
Size: 6391 bytes
Desc: not available
Url : https://cabforum.org/pipermail/public/attachments/20130801/13dc80d3/attachment.bin