[cabfpub] Concerns regarding Mozilla Root Program/Baseline Requirements
wthayer at godaddy.com
Fri Aug 2 01:01:27 UTC 2013
This works for me and I support it, especially in light of the 60 vs. 39 month issue that Steve has pointed out. I also think we need to define what rekey means and I'll gladly help with that.
I also agree strongly that we need to address this immediately, whatever the outcome, since there are clearly different interpretations.
Ryan has raised what I see as a separate issue that's less time sensitive and probably requires a bit more discussion around changing policy OIDs to reflect CPS changes. My recommendation is to work on that after we decide on the rules regarding rekeys.
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'
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?
> -----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
> >>> 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-
> >> why not the validity period? Is it just that it's a commercial
> >> PITA,
> >> is there another reason?
> > [RWS] No other reason, commercial PITA pretty well sums it up. For
> > reasons, I prefer to avoid having customers scream at me if at all
> > 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
> >>> 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
> >>> 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
> >>> of the BR allowed term (5 years from now). Both of those things
> >> 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
> >> shorter than 5 years - that seems a long time to get rid of bad
> >> - 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
> >> year validity period were a good idea, and clue him in :-)
> >> Gerv
More information about the Public