<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">On Tue, Aug 27, 2013 at 10:43 AM, Rick Andrews <span dir="ltr"><<a href="mailto:Rick_Andrews@symantec.com" target="_blank">Rick_Andrews@symantec.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Ryan,<br>
<br>
Some of my colleagues were concerned with your statement "any and all certificates". Can you please clarify that checks for long-lived certificates will be limited to<br>
  a) end-entity certificates, that<br>
  b) are subject to BRs (SSL and EV Code Signing that chain up to public roots)?<br>
<div><br>
-Rick<br></div></blockquote><div><br></div><div>This is correct.<div><br></div><div>Our concern with Chrome is ensuring the Baseline Requirements are followed by all publicly trusted CAs (i.e. that participate in Root Programs on platforms on which Chrome runs). In this specific case, the focus is on end-entity certificates with invalid validity periods, as defined by the Baseline Requirements certificate profiles.</div>

<div><br></div><div>However, please be aware that we are actively evaluating further programatic checks to ensure technical conformance with the Baseline Requirements and the Baseline Requirement certificate profiles. Specifically, certificates (including intermediates and roots) issued after the effective date that fail to match the agreed upon profile may, at a minimum, not be treated as secure, and may invoke further investigations.</div>

<div><br></div><div>I should also note that this policy does not make special exemptions for certain classes of certificates. For example, Mozilla has, via their Root Program, exempted "technically constrained" certificates from certain audit requirements. With regards to technical requirements and certificate profiles, our view is that the Baseline Requirements should apply to all CAs and certificate issuance, and certificates that do not conform should not necessarily be treated as secure or trustworthy within Chrome. The technical constraints provide a means for CAs to limit risk and liability - to themselves, their customers, and to the Internet at large - but they do not provide an escape hatch for insecure practices.</div>

<div><br></div><div>Please be aware that we take the Baseline Requirements very seriously and hope that all CAs that are publicly trusted do so as well. If information is brought to our attention that is contrary to stated CP/CPSes or the BRs, this will naturally raise concerns about any and all BR-relevant audits that have been performed, whether to WebTrust, WebTrust EV, or another equivalent audit programs. As such, any decisions that were made on the basis of these audits - such as secure UI treatments or enhanced security UIs - will need to be re-evaluated in light of the information raised.</div>
<div><br></div><div>To (hopefully) be perfectly clear: Certificates that do not conform to the BRs that have been issued after the effective date of the BRs - July 1 2012 - are not guaranteed to be treated as secure in future versions of Chrome.</div>
<div><br></div><div>If CAs find there are questions about the BRs, or ambiguities in language that may create confusion, we certainly welcome discussions in the CA/B Forum. Hopefully we can continue to work together and clarify the language in the BRs, removing any ambiguities that may exist.</div>
<div><br></div><div>We applaud the CAs that, in spite of the absence of clear audit frameworks, took the proactive steps to ensure their issuance pipelines and CPSes complied with the BRs in time for the various effective dates. We regret that we did not have such technical checks ready to go on day one.</div>
<div><br></div><div>We hope that CAs will use this opportunity to proactively work with their customers who may have received such non-compliant certificates that should not have been issued. Hopefully this is a first step towards reaping the many benefits to Internet security that the BRs have worked towards for so long to promote.</div>

<div><br></div><div>Regards,</div><div>Ryan</div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div>
<br>
> -----Original Message-----<br>
> From: <a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a> [mailto:<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a>]<br>
</div><div><div>> On Behalf Of Ryan Sleevi<br>
> Sent: Monday, August 19, 2013 10:27 AM<br>
> To: CABFPub<br>
> Subject: [cabfpub] Deprecating support for long-lived certificates<br>
><br>
> This message is a follow-up to the thread originally started three<br>
> weeks ago at <a href="https://cabforum.org/pipermail/public/2013-" target="_blank">https://cabforum.org/pipermail/public/2013-</a><br>
> July/001976.html<br>
><br>
> As a result of further analysis of available, publicly discoverable<br>
> certificates, as well as the vibrant discussion among the CA/B Forum<br>
> membership, we have decided to implement further programmatic checks<br>
> in Google Chrome and the Chromium Browser in order to ensure Baseline<br>
> Requirements compliance.<br>
><br>
> These checks, which will be landed into the Chromium repository in the<br>
> beginning of 2014, will reject as invalid any and all certificates<br>
> that have been issued after the Baseline Requirements Effective Date<br>
> of 2012-07-1 and which have a validity period exceeding the specified<br>
> maximum of 60 months. Per the Chromium release cycle, these changes<br>
> can be expected to be seen in a Chrome Stable release within 1Q 2014,<br>
> after first appearing Dev and Beta releases.<br>
><br>
> Our view is that such certificates are non-compliant with the Baseline<br>
> Requirements. Chrome and Chromium will no longer be considering such<br>
> certificates as valid for the many reasons that have been discussed<br>
> previously on this list.<br>
><br>
> We also believe that such practice is inconsistent with the audit<br>
> criteria based upon the Baseline Requirements. For example, the<br>
> WebTrust Principles and Criteria for Certification Authorities 2.0,<br>
> Section 6.3, provides illustrative control #7 - that "The CA or the RA<br>
> verifies that the Certificate Rekey Request meets the requirements<br>
> defined in the relevant CP" and illustrative Control #14 "Prior to the<br>
> generation and issuance of rekeyed certificates, the CA or RA verifies<br>
> the following: ... that the request meets the requirements defined in<br>
> the CP."<br>
><br>
> As such, we would like to encourage the auditor community to pay<br>
> attention to such practices when evaluating Certificate Policies and<br>
> Certification Practice Statements.<br>
><br>
> Our choice of the beginning of 2014 was chosen as a balance of<br>
> ensuring the Baseline Requirements remain an effective goal for the<br>
> industry and a recognition of the roughly 2038 certificates that have<br>
> been issued since the effective date that do not conform to the BRs in<br>
> this regard. We encourage CAs that have engaged in this unfortunate<br>
> practice, which appears to be a very limited subset of CAs, to reach<br>
> out to affected customers and inform them of the upcoming changes.<br>
><br>
> Kind regards,<br>
> Ryan Sleevi, on behalf of the Google Chrome Team<br>
</div></div><div><div>> _______________________________________________<br>
> Public mailing list<br>
> <a href="mailto:Public@cabforum.org" target="_blank">Public@cabforum.org</a><br>
> <a href="https://cabforum.org/mailman/listinfo/public" target="_blank">https://cabforum.org/mailman/listinfo/public</a><br>
</div></div></blockquote></div><br></div></div>