[cabfpub] Concerns regarding Mozilla Root Program/Baseline Requirements

[Rich Smith]

To clarify, I was honestly not sure how our system would treat a re-key in
this situation, but in discussing internally, Rob has assured me that our
system prevents any issuance, even re-keys from having a Valid To date
further out that 60 months from the date of issuance, so our current
practice is to knock off time if necessary.  Comodo has not issued re-keys
in contravention of the BR rules.  My guess is that we probably haven't had
more than a very small handful of requests to re-key any 'long life'
certificates, or I would likely have had to explain to at least one customer
why we cut time off it.  That being said, I would personally rather be able
to honor the full term we have sold to our customer.  At this point, I'm
really more concerned with the certificates which will be affected by the
change over from 60 months to 39 months than I am with the small number of
'long life' certificates we have out there for which the client MIGHT ask us
for a re-key.  If the consensus is to exclude doing anything for the 'long
life' certs that were issued prior the BRs, I really have no strong
objection, but I would still like to discuss and consider coming up with
some kind of acceptable compromise for the 60 to 39 month switch over.
-Rich

> -----Original Message-----
> From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org]
> On Behalf Of Sigbjørn Vik
> Sent: Friday, August 02, 2013 6:56 AM
> To: public at cabforum.org
> Subject: Re: [cabfpub] Concerns regarding Mozilla Root Program/Baseline
> Requirements
> 
> I think the BRs are clear on what they require, and the EV definitions
> clearly spell out that renewals and reissuances create newly issued
> certificates. All new certificates require valid validity periods.
> While I can understand that people may want to discuss if the rules are
> optimal, I dislike CAs claiming ignorance of the rules, or exception to
> the rules since they have done things differently in the past. If
> someone wants to claim the rules are unclear, do so before assuming a
> particular interpretation, not afterwards.
> 
> Opera is happy to work with the group to define optimal rules, but we
> dislike CAs engaging in creative reinterpretation of the rules. If we
> can't trust that CAs follow the rules decided upon, then the rules are
> close to worthless.
> 
> In addition to reasons mentioned previously about why constrained
> validity periods is a good idea, there is also the point about the web
> moving forwards. For us to be able to upgrade requirements, ditch
> insecure practices, and promise a secure experience in the future, we
> need to limit the time limit of certificates today. This is basic
> insurance for the web in the future. Any exceptions we carve out today,
> take away from this insurance, and might end up costing us a lot. This
> is not a zero-sum game, and decisions we make today might have serious
> consequences some years down the road.
> 
> This discussion has also highlighted some other issues:
> * It seems some CAs are happy to issue backdated certificates. We
> should probably spell out that signing, issuance and first validity
> dates should all be as close as possible, with a maximum discrepancy
> allowance.
> * To be able to verify this, we should also require that any CT
> registrations happen within that time limit. I will contact the CT team
> and ask them to consider this.
> * It seems audits don't catch CAs issuing certificates contrary to the
> BR. What can we do to ensure that audits catch such issues?
> * Does the CABForum need an explicit objective?
> 
> On 01-Aug-13 15:08, Rich Smith wrote:
> > 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.
> 
> For CAs not to follow the BRs would presumably open them to lawsuits
> from those who rely on the CAs for trust. For browsers not to follow
> due diligence and best practices would presumably open them to lawsuits
> from their customers. So if you care about potential lawsuits, the
> score is
> 2-1 for not issuing such certificates. However, I think potential
> lawsuits are irrelevant. The goal of this group should be to secure the
> web, not to ensure the short-term profits for individual members. (See
> the last point above, about an objective.)
> 
> On 01-Aug-13 17:00, Steve Roylance wrote:
> > [...] 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.
> 
> That would be strange. Since the BRs were adopted in November 2011, all
> CAs have known (and been audited on) the fact that after 1 April 2015
> the maximum validity period is 39 months. For CAs today to sell
> certificates valid more than 39 months past that date, and promise to
> reissue them at any point would be shooting themselves in the foot.
> 
> --
> 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: <http://lists.cabforum.org/pipermail/public/attachments/20130802/8b82b2a7/attachment-0003.bin>