[cabfpub] Concerns regarding Mozilla Root Program/Baseline Requirements

Jeremy Rowley jeremy.rowley at digicert.com
Thu Aug 1 13:23:05 UTC 2013


By that rationale, anyone could effectively bypass the BRs by quickly
getting a contract with a customer that states something to the contrary of
pending standards. We are expecting everyone to revoke their certificates
related to internal server names well before their expiration date, possibly
breaking some contracts, in response to the new gTLDs and internal server
name deprecation timeline.  I don’t see a difference.

Jeremy

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On
Behalf Of Rich Smith
Sent: Thursday, August 01, 2013 7:08 AM
To: 'Sigbjørn Vik'; 'Ryan Sleevi'; public at cabforum.org
Subject: Re: [cabfpub] Concerns regarding Mozilla Root Program/Baseline
Requirements

Ryan and Sigbjorn,
I disagree with your interpretation regarding a certificate
replacement/re-key.  

It is an almost universal practice in the industry to allow a customer to
have a certificate re-keyed at any time during that certificate's life
cycle.
I can see where GoDaddy's practice of changing the valid from date on a
re-key could cause some confusion.  I think a re-key should leave the
validity dates as originally issued but from a customer service perspective
I can see Wayne's point for why GoDaddy changes the valid from date.

I don't want to speak for all CAs, but based on past discussion of various
topics, I think most of us consider the BRs to be binding on NEW
certificates, and do not consider a replacement/re-key a NEW certificate.  I
do consider a RENEWAL to be a NEW certificate because the originally agreed
upon term of validity has expired at that point.

Taking Ryan's definition and subsequent logic would effectively nullify all
pre-BR agreements made with thousands of CA customers who bought
certificates for terms greater than the now allowed 60 months max (and soon
to be 39 month max).  My lay opinion is that such action would open the CAs
to lawsuits for breach of those agreements.

I would also tend to agree with reasoning that stated that the CA, if doing
a re-key/replacement of an existing pre-BR, long life certificate were to
require re-vetting if the re-key/replace request falls outside the current
39 month limit for relying on previous verification.  I don't think that
would constitute a breach of contract, because we would not be nullifying
the time frame of the original agreement, we would simply be requiring
positive verification that the certificate details are currently accurate.
Mozilla's policy required this prior to the BRs.  They changed their policy
to conform with the BR after the BR was finalized.  My problem, and I
believe the contractual problem, is telling the customer that they are no
longer entitled to the term of validity to which both parties originally
agreed.

Regards,
Rich

> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Sigbjørn Vik
> Sent: Thursday, August 01, 2013 4:06 AM
> To: public at cabforum.org
> Subject: Re: [cabfpub] Concerns regarding Mozilla Root 
> Program/Baseline Requirements
> 
> On 31-Jul-13 18:47, Wayne Thayer wrote:
> 
> > This issue naturally goes away as these legacy certificates expire, 
> > and it is not a violation of our policies, nor do I believe is it a 
> > violation of the BRs.
> 
> We believe this is a clear violation of the BR. How fast can you stop 
> this practice, and revoke any certificates in violation?
> 
> On 31-Jul-13 20:40, Ryan Sleevi wrote:
> > Wayne,
> >
> > I appreciate your reply in explaining this further.
> >
> > Please understand our intent is not to single GoDaddy out, but our 
> > concern remains that this highlights a potentially dangerous 
> > disagreement upon what "issuance" means. Our concern stems from the 
> > fact that, in our view, issuance is the practice of signing a 
> > certificate.
> 
> While I agree that the signing in practice counts as the issuance (as 
> issuance normally happens only seconds afterwards), this is not the 
> correct definition. Issuance happens when certificates are sent to the 
> customer[1][2][3]. In particular, this definition stops CAs from 
> signing certificates before a deadline, selling (issuing) them 
> afterwards, and claiming governance by the old requirements.
> 
> If a single byte of a certificate is different from a previous issue, 
> then this is a new issue (as the customer did not have access to that 
> byte sequence beforehand), regardless of the name given to it, new 
> edition/version/rekey/...
> 
> [1] http://www.thefreedictionary.com/issue: "The act of circulating, 
> distributing, or publishing"
> [2] http://www.merriam-webster.com/dictionary/issue: "The act of 
> publishing or officially giving out or making available"
> [3] http://dictionary.reference.com/browse/issue: "The act of sending 
> out or putting forth"
> 
> --
> Sigbjørn Vik
> Opera Software
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public




More information about the Public mailing list