[cabfpub] Concerns regarding Mozilla Root Program/Baseline Requirements

Rich Smith richard.smith at comodo.com
Thu Aug 1 08:53:24 MST 2013


Some very good points, Steve.

Comodo doesn't have an extreme view on this TBH.  I disagree with Ryan's
reasoning, but at the end of the day I've got maybe couple hundred DV certs
that would be affected by the outcome of this discussion, IF they decide to
ask for a replacement today, and that number will continue to decrease as
the time remaining on those certs converges with the max allowed term in the
BRs.  It may become a slight pain in my neck, but this isn't a show stopper.

I just don't think this was made clear enough in the BR or in the
discussions leading up to it.  My main objection at this point is simply
that I don't think that cutting the effective, agreed upon life-cycle of
these certificates either adds to or detracts from the overall security of
the internet enough to justify even that admittedly very small amount of
pain.

-Rich

> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Steve Roylance
> Sent: Thursday, August 01, 2013 11:01 AM
> To: public at cabforum.org
> Subject: Re: [cabfpub] Concerns regarding Mozilla Root Program/Baseline
> Requirements
> 
> Dear all,
> 
> I think it's fair to say that there is simply a lack of common
> understanding concerning key and certificate lifecycle management.
> Please note that CABForum has tried to define some of the terms in the
> past to help, but they may have hindered as they were for EV, where
> duration was already agreed, so there were no instances of legacy
> certificates to cause confusion.
> 
> 
> >From EV 1.4
> 
> * EV Certificate Renewal: The process whereby an Applicant who has a
> valid unexpired and non-revoked EV Certificate makes an application, to
> the CA that issued the original certificate, for a newly issued EV
> Certificate for the same organizational name and Domain Name prior to
> the expiration of the Applicant's existing EV Certificate but with a
> new 'valid to' date beyond the expiry of the current EV Certificate.
> 
> * EV Certificate Reissuance: The process whereby an Applicant who has a
> valid unexpired and non-revoked EV Certificate makes an application, to
> the CA that issued the original certificate, for a newly issued EV
> Certificate for the same organizational name and Domain Name prior to
> the expiration of the Applicant's existing EV Certificate but with a
> 'valid to' date that matches that of the current EV Certificate.
> 
> 
> As it stands GlobalSign, Like Symantec does not have a dog in the
> duration race as we do not have any certificates longer than the
> current 60 months, so any re-issuance would not break the BR rules,
> however, in 2015 when the industry flips to a 39 month max I believe
> from my engineering team we would have had a similar issue to others,
> again due to the existing contract precedence understanding that others
> have mentioned.
> 
> Once we all solve our combined general understanding on this point we
> need to ensure we also cover the other areas the duration subject
> raises.
> Namely:-
> 
> 1) If the intention of duration is to limit the useable duration of the
> key then the current BRs do not achieve this as they talk about
> certificates meaning a CA that uses any sort of "renew" operation would
> simply sign the same key again so what's the difference here?  Two back
> to back 5 year certificates with the same key is ostensibly the same as
> one ten year one if you are trying to crunch the key.
> 2) Even if each CA were to look at their own database of issued
> certificates to prevent renewal after a certain period of time, any
> customer is open to moving to another CA and using the same CSR so we
> are again back to 5+5=10.  (Maybe CT would help here?)
> 
> I suggest a discussion in the September Face to Face with homework for
> each CA to bring along their lifecycle charts so we can all exit with
> agreement on our terms.
> 
> Finally there's one other issue which rekey causes if certificates are
> keyed with a NotBefore date in the past.  Whilst for SSL this doesn't
> present a problem, for document signing and signing for individuals it
> does, as the statement made by the CA with respect to the status of the
> key at the point of issuance actually makes no sense and any previous
> CRLs from the past can be used in combination with the certificate at a
> modified signing date to make false statements.
> 
> Finally, Finally I'm led to believe that adding serial numbers to CRLs
> with expiry dates in the past (think prior to malware being signed) may
> also be problematic.
> 
> All these lead me to suspect that CABForum members continue to work
> together to find a level playing field where everyone follows the
> rules, the rules make sense and everyone remains protected.
> 
> Let's move forwards one step at a time.
> 
> Steve
> 
> 
> On 01/08/2013 14:56, "Jeremy Rowley" <jeremy.rowley at digicert.com>
> wrote:
> 
> >Agreed.
> >
> >-----Original Message-----
> >From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> >On Behalf Of Gervase Markham
> >Sent: Thursday, August 01, 2013 7:46 AM
> >To: richard.smith at comodo.com
> >Cc: public at cabforum.org
> >Subject: Re: [cabfpub] Concerns regarding Mozilla Root
> Program/Baseline
> >Requirements
> >
> >On 01/08/13 14:43, Rich Smith wrote:
> >> The subject we're currently discussing was not spelled out clearly
> at
> >> all, and my recollection regarding the discussions around validity
> >> period was that it was well understood that there were long lived
> >> certificates out there, and that they would be allowed to live out
> >> their
> >life-cycles.
> >
> >There's a difference between allowing a cert to live out its life
> cycle
> >because it's unreasonable to ring up a customer and tell them to make
> a
> >change to their running system, and the situation where they are
> >already making that change and you have an opportunity to issue them a
> >replacement cert which is BR-compliant.
> >
> >> Certificate duration has the potential to effect a much larger
> number
> >> of customers and I don't think those of us who have issued them in
> >> the past would have agreed to specific terms in the BR stating that
> >> we would have to revoke them, absent any other security
> >> vulnerability, had that been clearly stated from the outset.
> >
> >This is not a request for revocation, it's a request that newly-minted
> >certificates conform to the BRs, even if the cert they are replacing
> >did not.
> >
> >Gerv
> >_______________________________________________
> >Public mailing list
> >Public at cabforum.org
> >https://cabforum.org/mailman/listinfo/public
> >
> >_______________________________________________
> >Public mailing list
> >Public at cabforum.org
> >https://cabforum.org/mailman/listinfo/public
> 
> 
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
-------------- 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/71993d8d/attachment.bin 


More information about the Public mailing list