2014-01-30 Minutes
MINUTES OF CA/BROWSER FORUM
30 JANUARY 2014
Dean Coclin read the antitrust statement at the bottom of the agenda.
1. Roll Call: Dean Coclin, Eran Messeri, Rick Andrews, Kirk Hall, Eddy Nigg, Doug Beattie, Eneli Kirme, Mads Henriksveen, Sissel Hoel, Gerv Markham, Imren Altepe, Robin Alden, Atsushi Inaba, Ryan Sleevi, Tom Albertson, Rich Smith, Ben Wilson, Wayne Thayer
2. Agenda Review: Dean reviewed the agenda and no changes were made.
3. Minutes: Minutes of 2 January 2014 were approved. (The meeting of 16 Jan 2014 was cancelled.)
4. Discussion of Ballots: Ballot 114 – EV Definitions passed. Voting on Ballots 110 and 115, dealing with bylaw revisions for associate members and invited guests and Entrust/Bruce Morton, starts on 30 January 2014.
5. Participation of Cisco as Associate Member: Dean said that Cisco had asked again about the status of their inquiry into Forum membership. He noted that we had discussed this in November and that Cisco is not clearly either a CA or a Browser and that it has some elements of both. He said he previously distributed information about the methodology used by Cisco to manage its root store. Until we come up with a new definition of trust anchor managers, as mentioned by Tom, Dean would like to recommend that Cisco be invited to participate as an associate member. That way they could attend but not vote, similar to PayPal, ICANN, ETSI, WebTrust and others.
Gerv asked whether associate membership was part of the bylaws yet. Dean clarified that associate membership is in Ballot 110. Kirk reconfirmed that when the bylaws were drafted, associate membership was not specified but that the Forum had followed its de facto treatment of them. Ryan S. said that there is no associate member category, but we do have interested parties. Gerv said that during the meeting in Turkey, we worked on a round of revisions to the bylaws to clarify what types of members there are. Ben said that Cisco could fit into the current “Interested Person” category. Dean said that the bylaws provide that interested parties can participate by completing the IPR agreement.
Gerv suggested that we invite Cisco as an “Interested Party”, saying that we will clarify this and soon they will be an associate member if this passes and that is effectively the same status and then they can participate in the discussions of how exactly we define browsers going forward. There were no objections to inviting Cisco as an “interested Party” as long as they sign the IPR. Dean will reach out to them.
Dean read Cisco’s reasons for wanting to join. Cisco is interested because they are operating a CA/B Forum compliant sub-CA subordinated under the Identrust root, and they are in the process of setting up another publicly trusted root which will be compliant with CA/B Forum standards from the get-go. Cisco SSC CA 2 is already fully WebTrust for SSL CA certified as of this year and has been WebTrust for CA Certified for several years, and the new root representing Cisco is an investment in customer services that require a publicly trusted root. Given how important that can be to their business and products, they want the chance to contribute to the standards that will determine the playing field. Their PKI trust pool originates from Cisco’s trusted root project. They are restricting the contents of that root pool this year, as well as establishing new root stores that can be used for certifying third party code or applications on Cisco products, or for certifying connections to or through them. Standards like those of the CA/B Forum represent a chance to exchange information with peers in that space and to establish cross-company guidelines for root stores that foster consistency. It is also a good way to demonstrate Cisco’s ongoing commitment to transparent, secure, and open standards for cryptographic security on the internet and helps calm concerns created by the recent NSA fallout. They have always operated above board and want to continue to assure their customers that they are trustworthy while encouraging and fostering standards by bodies like the CA/B Forum that encourage open and verifiable security standards.
Gerv thought they sounded more interested in being on the CA side than on the Browser side. Dean said they mentioned the PKI trust store, which is more like a browser. Ben suggested that they are a hybrid, and no definition exists for them yet. We have always had to pick which one you’re in, but in this kind of situation, I don’t know if we want to follow that history. We might need to define another membership type.
Gerv said that if they are an interested party, it doesn’t matter which side they are on, but if they are going to join they have to pick one, because the one you pick depends on how your vote is counted. Gerv thinks that Cisco seems to be more in the CA business than other browsers.
Dean said that if they come to the face to face, we can talk about it there, but it doesn’t look like they will have submitted their signed IPR agreement by then.
Kirk suggested that the browsers move forward with their own ideas of a definition of a browser so that we can get the bylaws the way we want them. He suggested that the browsers come to the Mountain View meeting with a proposed membership definition for the bylaws.
Gerv mentioned that he had started writing an email on that topic, but what he was missing was a clear and full understanding of the issues with the current definition. There are companies that we gut feel should qualify as browsers, but don’t. Having a list of those companies would be useful. Ryan agreed. The definition flows out of principles and what kind of organizations we think should be members in order for the CA/B Forum to be effective. If we start to write a detailed definition without having an agreement on what we’re trying to achieve, it’s not going to work. Do we need to start a discussion on the mailing list to determine what that would be?
Ryan said a big part of the interest in defining the definition of the Browsers is the increased scope of the Forum with code signing. In particular, the code signing working group, as opposed to focusing on SSL/TLS. We need to address the increased role of the Code Signing working group, and when to permit organizations when they care about code signing, but might not necessarily care about SSL/TLS. We need to understand what organizations we want to have as members, but changing the definition of browser to the point of meaninglessness creates concern for those already deeply involved in improving the SSL/TLS ecosystem. He would like to see the names of those who we believe should be members as browsers, and the browsers can look into it, and try to find a way to expand the definition, or look for ways that they actually meet the current definition. Because there hasn’t been a demonstrated problem with the current definition we just need to understand why you want to expand it.
Ben said the list of those entities is as simple as Oracle and Cisco, but he wasn’t sure what the definition of that group would be. Gerv mentioned that Oracle qualified because they run a root store built into Java.
Ryan said that it sounds like from what Dean read, that Cisco is planning on running a root store of their own. Dean clarified that Cisco has operated a trusted root store for quite some time. All Cisco products have the feature called PKI Management and they have over 100 products. They perform an analysis of three major root stores: Microsoft, Apple, and Mozilla. If the root appears in all three stores, they include it in their bundle.
Gerv said that independent trust decisions, rather than taking someone else’s decisions, is an important part of being a browser. Positive security decisions are important as well–taking an algorithm based on someone else’s decisions is not sufficient to qualify as an independent root store operator. So, if what we are looking for is a root store operator, a root store operator is someone that has a program and criteria for making independent trust decisions.
Additional discussions should follow at our face to face.
6. Planning for Mountain View and Eilat
Working groups will meet on Tuesday, 18 February 2014. The proposed schedule for working groups is (Pacific Standard Time UTC-8):
09:00-10:30 RFC 3647 Conversion Group
10:30-12:00 SSL Performance Working Group – SSL Profiles
12:30 – 2:30 Code Signing Working Group
3:00 – 5:00 Extended Validation Revisions Working Group
Ben will start an online agenda for the Wednesday and Thursday meetings.
Certificate Transparency will be discussed at 9:00 am on Wednesday or Thursday to accommodate remote participants in European time zones.
Although this is not a business operations issue, Ben will be putting together a tour of Petra, Jordan, on Thursday, June 19, for those interested.
7. Continued discussion about Certificate Transparency
Eddy said that he has discussed his position about Certificate Transparency with Eran Messeri of Google, but he also requested the opportunity to present and record his position (and that of others he’s talked to) with the CA/Browser Forum. His first point was that the pre-certificate process is extremely difficult. There is a huge difference between “the intention to issue” a certificate and the actual “issued certificate”. Certificate requests can come in a variety of ways. For most CAs, a certificate request will proceed through multiple stages and layers of the CA infrastructure until it is eventually approved and a certificate is issued. In some situations, a certificate presented to the CT log as a pre-certificate might not get issued later on. In some CA infrastructures, there might be no ability to communicate with a transparency log server during this process (scrivener’s note: because it could open up a firewalled network to an external attack). Some CAs will not communicate with an outside source for security policy reasons – especially “at the point where the CA is about to issue the certificate”. Yet communications from Google indicate that the pre-certificate should be submitted to the Certificate Transparency log as one of the very last steps in the issuance process. Eddy does not want to insert something into a certificate at the very last moment.
Ben asked Eddy for clarification on this point and whether CT proofs could be provided at a different time during the process and what did he mean when he said that it is supposed to be one of the very last tasks. Eddy said that if you look at EV certificates, which involve a lot of manual review by staff before you issue the certificate, CAs could probably manage such process and create a pre-certificate, but this cannot be done for non-EV certificates, for which some are partially automatically issued. The process would be different. He would have to point to the CT log at a very early stage for these types of certificates. Then if the certificate request is rejected, it is problematic because there would be a record in the log for something that never posted. CT currently does not allow removal or revocation of a record. CT log would then be inaccurate, because it would say that a certificate has been issued when it has not. If anyone does implement this pre-certificate, it should instead be called something like a “certificate signing request” and not a “certificate”. Eddy’s main concern is that they cannot and will not go online to perform the pre-certificate process as a last step in an automated process.
Ben said he would prefer that we not have multiple different types of implementations, but he understood Eddy’s concerns. Since Google was able to go out and create a pre-populated certificate transparency log based on discovered certificates, based on issued certificates and not pre-certificates, he wondered whether there were other solutions, but he noted that we need to keep in mind these questions, “what is the problem we’re trying to solve?” , “does the proposed solution solve that problem”, and “when it is all said and done, did we solve the problem that we sought to solve in the first place?”
Eddy said that his second concern is privacy. We should not be telling everyone in the world about certificates issued for internal systems. We don’t publish certificates, even though certificates that are used publicly become known. He said he would discuss an alternative later, but that another issue is the overlap between Certificate Transparency and OCSP and CRLs. CT has a list of certificates and OCSP today must have a list of certificates. Now, if a browser could ask CT about whether a certificate is valid or not, it could relieve CAs from having to provide OCSP, and they could use those resources to maintain CT logs rather than OCSP as a more cost-effective solution, at least for us.
Eddy: The timeframe that Google suggested for implementing CT is unrealistic because for non-EV we cannot implement it in any case. Eran has made me aware that Google, Apache, nginx, and maybe other web servers are working on an extension for certificates that they see at their servers can submit them to a CT log and receive back a signed timestamp which will be delivered by a TLS extension by the very same server providing the certificate. This is a post-issuance solution that I believe would work well for two reasons: (1) the certificate already exists, and (2) the reporting is done by the owner of the certificate, and this resolves the privacy issue. Google has said that there is a problem because it will take time until web servers can handle this process with such a TLS extension, but I believe that is good because this technology is new and still has to be learned and it must be operational without problems, and then we still have support issues to be concerned about. So bottom line is that this should be done by the servers.
Eran: Regarding privacy, that was also mentioned by Rob Stradling. We now believe we have a solution that will be in the next RFC. Specifically, if you want to look at it, it is Issue #20 for the discussion of RFC6962-bis / Certificate Transparency issue tracker. As for the timeline, one option is to implement a whitelist, for existing issued EV certificates for example, so we don’t have to wait for all certificates to expire and be replaced with new ones that support CT, and we can have a whitelist in Chrome.
As for the Apache change, we are working on it, with dependencies on other libraries also. They have been submitted and are available. We haven’t announced anything because we don’t believe in announcing anything that is not done yet, but it is one direction that will help some site admins, but as an only solution it would be very difficult to successfully deploy because each and every web server would have to support it.
Ryan: For Chrome and its requirements for EV, Certificate Transparency serves a broader purpose than what Eddy has highlighted on this call and what others have on the list. Certificate Transparency is an important complement to public audit requirements. We are strong believers in the public audit. Given the incidents that we’ve seen over recent years, public audit is going to increasingly become a requirement for participation of public recognition of EV and eventually of SSL, as stated in previous emails. Eddy has highlighted it as a statement of revocation, but we view it as more than revocation, but as a part of public audit. Because CAs are publicly trusted by our program, we’re going to increasingly require baseline requirements audits the same way we require WebTrust for EV.
Eddy: The funny thing is that EV certificates probably have the least need to be in the CT log. Maybe it is the best way to learn it, and easier to implement, as I’ve said before, and there have been fewer misissuances because of the requirements involved. Thanks for the opportunity to explain our position.
Tom: Could Ryan clarify Chrome’s position on Certificate Transparency and audits?
Ryan: Certificate Transparency will be part of Chrome’s program requirements just like Mozilla’s program has Baseline audit requirements, and Microsoft has requirements on certificate serial numbers and an agreement as part of its program. Such program requirements go beyond common requirements. For Chrome, we would require audits for baseline and EV, but in addition to those, we will require CT as part of our program requirements because having a publicly auditable log is an important part of participating as a publicly trusted root, at least for our users, recognizing that other browsers may have other opinions on that.
8. Report on ETSI CA Day Meeting
Dean said that Ben, Robin, he, and other members of the CA / Browser Forum were at the ETSI CA Day meeting hosted at TuVIT in Berlin on January 16, 2014 and that he and Ben wrote a blog post available here: https://casecurity.org/2014/01/24/ca-day-in-berlin/. Presentations from the meeting are available here: https://www.tuvit.de/de/unternehmen/downloads-1898.htm.
9. Working Group Updates
The EV working group continues work on ballots to present to the Forum. A draft of the Baseline Requirements for Code Signing certificates was distributed by Tom recently. Working group members should start preparing for the face-to-face meeting by getting up to speed on the list of tasks they are working on. The SSL Performance working group should be looking at certificate profiles.
10. Any Other Business
None.
11. Next phone call - Thurs. Feb 13th
12. Adjourn