Summary of CABF face-to-face Meeting 32 in Eilat
Mon. 16 June 2014
Performance Working Group
Wayne reviewed the discussions to date, which have involved certificate size, the initial TCP congestion window, and the number of SANs in a certificate. The group decided that we could wrap up work by the group with a summary document that explains some of the considerations to be made when attempting to maximize SSL performance. It would be built from a presentation that Wayne had given internally to people at GoDaddy. Once the working group has completed the document, we would review it once every year and keep it up to date. It was decided that Wayne could lead this effort as the sole working group chair in order to wrap up this work.
Code Signing Baseline Requirements (summary of both days)
The document is being finalized for initial release to software publishing houses for review. The following terms were discussed: “AV Vendor” (to use that term, rather than “Malware Database Provider”) and “Significant Volume” (to modify the language so that CAs notify root store operators a certain number of days in advance of ceasing to support validation of such certificates). Rick was going to provide suggestions for this language. We discussed private key protection and language was clarified by splitting the section into two with a new section created specifically for signing services. The validity period of timestamping certificates (but re-key every 15 months). We also decided to leave in the reference to “RFC 2527”, in addition to RFC 3647, even though RFC 2527 is superseded by RFC 3647. Dean also introduced the idea of performing identity verification by requiring recent photographs of applicants with their photo IDs. This could be integrated into the Declaration of Identity document process. The security of signing services will be harmonized with the current Network and Certificate System Security Requirements. Don said he would review a draft with an eye for auditability.
EV Improvements (summary of both days)
We reviewed 11.7.2 (Ballot 127) and decided it is ready to move to review-and-vote. A proposal to simplify the EV roles was discussed, and it was decided that it needed more work before being presented to the full group. The re-use of documentation proposal (Ballot 123) was discussed. Kirk suggested that the ballot be re-phrased to focus on just the key issue–that no certificate can be issued based on information that is older than 12 or 13 months. Wayne and Jeremy explained that the key motivation behind this change is primarily that the current language is convoluted and confusing, so that is why Ballot 123 is needed. Moudrick expressed concern that some language in the guidelines might allow an employee of one subsidiary to communicate falsely as if they had authority to communicate with the CA on behalf of all affiliates.
Ben believes that the liability insurance for EV issuers required under Section 8.4(b) still does serve to protect third parties, and he does not want to allow Section 8.4 to be removed from the EV Guidelines without another insurance requirement in place. Jeremy is collecting information about legal requirements for insurance in various jurisdictions, and Ben is gathering information on the appropriate wording based on the policies that are available globally with global coverage.
Tue. 17 June 2014
Microsoft is investigating a change to its program to disable CRL download and only use OCSP, but it is also wondering why it hasn’t seen larger CRLs in light of Heartbleed. Microsoft already intends to use its “untrusted list” to revoke CA certificates, which is similar to Google’s CRL Sets but would be all-inclusive of CAs that are revoked. Microsoft wants prompt notification about CA revocation. The group thought it would be good if all browsers could at least use the same procedure for CAs to communicate with browsers when notifying them about CA certificate revocation.
Mozilla wants revocation to work fast (e.g. OCSP stapling). It is also implementing key pinning – Twitter, Google, etc. in upcoming releases. Mozilla::pkix is in Firefox 31 to be released on July 22. Now is the time to test it with your CAs and certificate chains and submit your bugs. Other items of particular interest to Mozilla include: definition of SSL certificate for browser processing and Baseline Requirements, OCSP must-staple, and short-lived certificates.
There was discussion that updated information is needed from Google on the current status of its implementation program and whether there were any updates on CA requirements for supporting Certificate Transparency.
Reports from WebTrust and ETSI
Don suggested that the Forum take the time to carefully review and revise the Network Security requirements as soon as possible because they are effective for CAs whose audit years being after July 1, 2014. Also, WebTrust is tightening the auditor qualification requirements for performing CA audits.
The European Parliament adopted ETSI TS 102 042 as a European Norm and a Qualified Web Site Certificate, which will not be identical to an EV SSL certificate, but additional details on the ramifications of the legislation will depend on the Implementing Act, which is being developed by the European Commission. A CA Day has been scheduled in Berlin for November 2014.
All CAs are taking action to sunset SHA1 certificates. For some uses of SHA1, like code signing, the move to SHA2 should happen simultaneously—the certificate, the OCSP response, and the timestamp should all be signed by the same signature algorithm. Better outreach is needed with instructions on how to do this with signing tools, etc. Eddy noted that many systems are not ready for SHA2. Windows 2003 Server has a special update available, but it is set to end-of-life next year. Some customers have trouble making the move to SHA2, so they come back and ask for a SHA1 certificate. Kelvin encouraged CAs to contact him if they have specific examples. Eddy asked if Kelvin he had any statistics available on how many Windows 2003 servers were in use.
Public Suffix List
Gerv explained that the Public Suffix List is an attempt to map the structure of the public domain namespace. https://publicsuffix.org/list/effective_tld_names.dat The PSL is divided into two segments/divisions. It is important for CAs to focus just on the “BEGIN ICANN DOMAINS” division. The Baseline Requirements need to be updated / clarified to say that (for wildcard checking and for the CA’s general evaluation of what is the customer-owned domain name).
Rick explained the background of CA / Browser Forum discussions on this topic. The group agreed that the ballot is ready to move forward with an effective date of 6 months after adoption (requiring that CPs and CPSs be updated by then).
Wed. 18 June 2014
NIST SP 800-52
Ben reviewed NIST SP 800-52 and will circulate his comments. The key take-away is that all U.S. federal systems must implement TLS 1.2 by January 1, 2015. Kelvin asked whether we need to update our profiles. Ben noted that they have a profile included as Table 3-1 that we should look at. We then discussed whether browser displays should downgrade security indications if servers are not offering support for connections using TLS 1.2.
What is an SSL Certificate?
We reviewed “what is an SSL Certificate?” and discussed the scope of the BRs – Doug will prepare the notes. Jeremy explained that the Baseline Requirements will be revised to define their scope of coverage to certificates that contain the server-auth EKU and for browsers to disallow server certificates containing no EKU or the anyEKU.
CA/Browser Forum Project Lifecyle / Bylaw Amendment
Moudrick introduced ideas on how to improve the CA/Browser Forum project lifecycle. Dean is preparing notes. Moudrick said that the Forum has various projects, for instance, the Extended Validation certificate, for which we’ve defined goals. Sometimes a proposal attempts to resolve an issue by bringing in subject matter that is not central to the project or goal. Jeremy said that he understood the scope of the CA/Browser Forum included anything dealing with CA operations. Kirk offered to review any changes to the bylaws that Moudrick wanted to propose.
NIST IR 7924 Reference CP
Dean reviewed NIST IR 7924 Reference CP and Kirk prepared notes. We decided to form a new working group to review the NIST Reference CP, along with ETSI documents, and to integrate sections 4 through 6 into the Baseline Requirements, including security, and to consider reordering the Baseline Requirements and EV Guidelines to match the RFC 3647 format. The WG would be open to Interested Parties, and would make recommendations to the Forum on what to do. Forum representatives who volunteered to serve on the new WG were Jeremy Rowley, Robin Alden, Ben Wilson, Moudrick Dadashov, and Dean Coclin.
OCSP Stapling Deployment by Apache / nginx
We discussed OCSP Stapling deployment and how to coordinate with developers of server software. Rick is preparing those notes. The group noted that OCSP stapling is critical, not only to enhance reliability and speed of revocation checking, but also to enhance the privacy of end users, and that Apache and nginx need to implement OCSP stapling by default. Software on hardware used to terminate end points need to support OCSP stapling as well. Iñigo said that he has trouble getting vendors like Cisco to support current protocols. Gerv said that from what he could tell, OCSP stapling has been included in mod-ssl, so it should be available to server vendors. Ben suggested we strategize on how to move this issue forward. Rick/Symantec, Doug/Ryan, Robin/Rob, Gerv, and others will begin an effort to reach out to their contacts. Gerv noted that one potential issue is the cache location for Apache to store stapled OCSP responses because several alternatives exist, yet none is selected by default. Each requires a different module to be loaded and placed in the database configuration. It was speculated that Open SSL does not have the ability on its own to make outbound http OCSP requests because it lacks an http library. In other words, the prerequisite for Apache to serve an OCSP stapled response in the handshake is a cache from which to pull its current OCSP status response.
We anticipate meeting in September in China, but we need to get the invitation letter and visa applications moving forward. Next year we are looking at Microsoft hosting in Redmond (Digicert as a backup), then SwissSign in Zurich, and then eTugra in Turkey (Izenpe in Bilbao as backup). In 2016 we are looking at Asia-Pacific, U.S. East Coast, and then Europe.
The group then adjourned, expressing great appreciation to StartCom and Eddy Nigg for hosting this face-to-face meeting in Eilat.