[cabfpub] Concerns regarding Mozilla Root Program/Baseline Requirements

[Rick Andrews]

Did GoDaddy's cert include their BR OID? That would be required to be in full compliance with the BRs.

-Rick

> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Rich Smith
> Sent: Thursday, August 01, 2013 1:34 PM
> To: 'Steve Roylance'
> Cc: 'CABFPub'
> Subject: Re: [cabfpub] Concerns regarding Mozilla Root Program/Baseline
> Requirements
> 
> 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