[cabfpub] Concerns regarding Mozilla Root Program/Baseline Requirements

Thu Aug 1 06:43:20 MST 2013

It's apples and oranges.

The main difference was that the revocation of internal name certs was
spelled out clearly and agreed to by all parties who agreed to the BRs.
There is also a clear security vulnerability regarding internal names in
certificates.

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.

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.
-Rich

> -----Original Message-----
> From: Jeremy Rowley [mailto:jeremy.rowley at digicert.com]
> Sent: Thursday, August 01, 2013 9:23 AM
> To: richard.smith at comodo.com; 'Sigbjørn Vik'; 'Ryan Sleevi';
> public at cabforum.org
> Subject: RE: [cabfpub] Concerns regarding Mozilla Root Program/Baseline
> Requirements
> 
> 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

-------------- 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/5a77ac49/attachment-0001.bin 