[cabfpub] Concerns regarding Mozilla Root Program/Baseline Requirements

Ryan Sleevi sleevi at google.com
Thu Aug 1 21:44:02 UTC 2013


Rick,

You can see that the secondary issue I raised was that the same policy
OID was used for the pre-BR policy (in which 10 year issuance was
permitted) and the current, BR-compliant CPS (in which 10 year
issuance is not).

Naturally, this is confusing, and probably worth a separate
clarification. As I've suggested on the Mozilla dev.security.policy
list, I think one thing that would be helpful is if the CP/CPS OID was
unique for every version (*including* any addendum - since I realize
some CAs don't version their CPS but continue to slap on addendum).
This would make it clear under what issuance practice the certificate
was done.

This would also require CAs to make all versions of their CP/CPS available.

Both of these things "would be good" - but I'd hardly suggest they are
the most concerning.

Cheers,
Ryan

On Thu, Aug 1, 2013 at 2:00 PM, Rick Andrews <Rick_Andrews at symantec.com> wrote:
> 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
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public



More information about the Public mailing list