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