Final Minutes for CA/Browser Forum Teleconference – July 20, 2017 (approved August 3, 2017)
Attendees: Adrienne Porter Felt (Google), Alex Wight (Cisco), Arno Fiedler (D-TRUST), Atsushi Inaba (GlobalSign), Ben Wilson (DigiCert), Chris Bailey (Entrust), Christopher Kemmerer (SSL.com), Dean Coclin (Symantec), Devon O’Brien (Google), Dimitris Zacharopoulos (HARICA), Doug Beattie (GlobalSign), Emily Schechter Pound (Google), Emily Stark (Google), Fotis Loukos (SSL.com), Frank Corday (Trustwave), Geoff Keating, (Apple), Gervase Markham (Mozilla), JC Jones (Mozilla), Jeff Ward (WebTrust), Ken Myers (US PKI), Kirk Hall (Entrust), Li-Chun Chen (Chunghwa Telecom), Mike Reilly (Microsoft), Patrick Tronnier (OATI), Peter Bowen (Amazon), Peter Miscovic (Disig), Rich Smith (Comodo), Ryan Sleevi (Google), Tim Shirley (Trustwave), Tyler Myers (GoDaddy), Wayne Thayer (GoDaddy), Wendy Brown (FPKI). 1. Roll Call 2. Read Antitrust Statement 3. Review Agenda. Agenda was approved. 4. Approve Minutes of F2F meeting of June 21-22, 2017. The minutes as amended were approved and will be posted to the Public list. 5. Governance Change Working Group. Ben said the WG had met and have a set of Bylaws and IPR Agreement revisions ready for final review and approval by the members. He suggested members may want their legal departments to review the changes as IP issues are involved. One issue the working group discussed was how to make certain new WG IPR requirements will continue to apply to a WG member even after the member leaves the WG. The proposal is ready for a vote. 6. Validation Working Group update. Peter said the WG had met and discussed Ballot 190 changes. The WG was also working on proposed fixes to existing validation methods. Peter had circulated draft changes to the Ballot 190 text, and some of the language might address issues brought up by people including Mads. 7. Policy Review Working Group update. Ben said the WG had a call the previous hour, and was close to completing its work on clarifying certain terms (CA, CA Operator, etc.) in the BRs. The WG had also followed up on issues raised at the recent CABF F2F meeting. Peter plans to send an analysis to the members for discussion. Dimitris said the F2F feedback was very helpful, and some ambiguities had been removed. 8. Network Security Working Group update. Dimitris said he had prepared a mark down of the Network Security requirements to help the WG’s efforts. Some possible “easy fixes” to the current NS requirements might be presented in an early ballot. There was also discussion on the handling of root keys. Bruce has provided more details in the WG Minutes he already circulated. Ken noted there had also been discussion about adding in multi-party control of roots as an alternative to multi-factor control, and possible clarifications about remote access. 9. WebTrust Task Force request for review of WTCA v2.1 changes. Kirk said that the WebTrust Task Force (TF) was ready to adopt changes to WebTrust for CAs Sec. 4.5 on CA key archival and destruction and new sections 4.9 and 4.10 on CA key transportation and CA key migration, as it was seeing a number of questions in those areas. However the Task Force does not ordinarily create draft requirements, but instead typically relies on requirements from other credible sources (such as ISO 21188 for the original WebTrust for CAs in 2000) to then create related audit criteria. Kirk said that Jeff Ward had clarified the Task Force was not asking the Forum to add the Sec. 4.5-4.10 changes to the BRs or adopt them in a formal CABF requirements document, but would like the Forum to formally approve the new audit criteria in a Forum Ballot. Kirk proposed to draft a Ballot for this purpose, and asked if any member objected. There were no objections. Ben thought that was a good approach. Kirk will present a ballot to approve the new audit criteria soon. 10. Discussion of common browser UI security indicators. Kirk noted that Mike and Curt has asked for time to discuss the possibility of common browser UI security indicators. Mike started off by saying he had brought the topic up at the F2F in Berlin, and being new to the Forum wanted to continue the discussion. His three questions were listed in the Public email he sent requesting time at the meeting, which were as follows: · Should browsers work toward a common browser UI security indicators related to certificates? · With the move to 100% encryption, what indicator should DV, OV, and EV sites receive? · Should we set up a new Browser UI Working Group within the Forum under the new governance structure to work on this topic? Mike first said he realized the subject of a common UI has been discussed extensively outside the Forum, but he and Curt wondered if the Forum would be the right place to have this discussion, yes or no, and then go from there. Gerv said that historically the Forum has shied away from requirements on browsers, as opposed to CAs. That’s partly due to the nature of the Forum, which is to provide consistency, certainty, and coordination for CAs in terms of root programs coming together to require the same things from CAs, rather than having CAs having to coordinate “n” different slightly varying root program requirements. Therefore we have these documents we all agree on together so that the CAs just have to follow the BRs rather than extensive and slightly varying policies from different browsers. That being the purpose of the Forum, the Forum has avoided the idea that it should mandate what browsers do. There’s also some resistance in some quarters of the browser groups for that because user interfaces, which is where such requirements might fall, are controversial topics. The research is ever ongoing and people want to validate the things that they do by “a-b” testing and do whatever works best for training users, and if you tie yourself down to a particular set of requirements and you find that something else actually works better but you’re not able to implement it – that’s not necessarily a position you want to end up in. Dean added that historically there’s been a reluctance ever since the EV Guidelines were started in 2006-07 from browsers to do anything that’s required or to listen to any requirements that might be put on them by CAs or other authorities in this area. That’s been sort of an ongoing, traditional stance that’s lasted over the last ten years. But Dean did think that because we are talking about security and security warnings, and the fact that you’ve got a global audience, it’s important to have some consistency amongst different browsers and different platforms, much the way that you have consistency in warnings in other types of things – whether it be automotive signs, etc. It makes it a lot easier for the public at large (and not the technical audience) who are using these tools to do commerce and transactions, shopping, whatever it is to have some sort of standardization around that, and Dean welcomed that Mike and Curt were bringing this topic to the Forum. Mike said that goes to his main point – a lot of those things are valid security discussions, but is the Forum the right place for that discussion? Ben said in response to Gerv’s and Dean’s comments, it’s not a prerequisite or mandate that anything be adopted or written in stone, but it would be good if the browsers would use some forum (whether provided by the CA/Browser Forum or some other group) to discuss these things, to collaborate a little bit, under the idea that if it isn’t done by themselves someone’s going to come along and say “it has to be done from a regulatory perspective.” There is that issue, and the browsers should take the opportunity to at least discuss what they’re doing so that they can provide a common presentation to the end-users that use various browsers. Ben said he used several browsers – maybe browsers assume people only use one browser (their browser). That’s the issue. Gerv said browsers are very far away from assuming that. He didn’t think anyone would argue that consistency is bad – consistency is clearly a good thing, but there are tradeoffs that come with mandating consistency, and it’s a question of whether the bad side of those tradeoffs outweigh the good. There is the second practical consequence that Gerv didn’t feel he was empowered to make commitments on behalf of Mozilla’s interface team. That doesn’t mean we couldn’t get them involved in such discussions but Gerv wouldn’t be the right person to take part in those discussions and make commitments on their behalf. Mike said he was in a similar position for Microsoft, and those conversations that he does have come around “you can have different OSs, challenges in getting consistent security indicator UI within a single ecosystem.” It’s also difficult when you combine different OSs, different browsers, different form factors, not that everyone is necessarily using a desktop, tablet, or phone - you can be doing things through apps that go into certain sites. And then also when technology starts moving away from passwords (one of the main concerns about phishing) you start thinking about biometrics, etc. Seems like a lot of things are kind of moving, where it gets difficult to get something consistent when you are considering all the different varieties of global users with different accessibility needs, things like that. It’s definitively a challenge. It kind of starts lending itself to more of a technical solution to some of the concerns when we are talking about phishing, malware, things like that, versus what users see and spending the time trying to train users versus trying to have technical solutions on the back end of the browsers. That’s the kind of conversation Mike ends up getting into. Adrienne said she appreciated the desire for more openness in the discussion around how security indicators are made. Google has tried in the past to be good about that by sharing some research and papers. Adrienne said she did like the idea of a public dialogue, but she echoed the previous concerns that standardization can slow down progress and the need to react as users’ needs change. Google discovered that some of its existing UI that had worked fairly well for its previous user base didn’t work so well for its user base in emerging markets and this caused Google to reevaluate its UI. This is something Google is able to do through user research relatively quickly, and if Google had had to go through a process where it had to get approval from a wider audience it would have slowed down Google’s ability to react to this need. Dean said there were certainly trade-offs to trying to standardize things – there’s a desire to have some commonality to help users understand things, but as Adrienne just pointed out there’s certain downsides to that. To go back in history, when the Forum started with the EV guidelines in 2007, the Forum tried to put in something that said if a browser encounters an EV certificate “make something green” – that’s all the Forum said to browsers, but that was heavily rejected. Apple said “absolutely not, we won’t take any dictation from CAs or anyone else on how we’re going to make our UI” – so that direction ended up getting trashed, and affected any future attempt on telling browsers what to do. But, as previous speakers have said, it would be interesting to have some sort of forum or group get together and work together on ways they could enhance and make some commonality amongst these security indicators. But Dean did fear what was just said about being able to iterate in response to new and emerging markets or other types of user platforms that might hinder the ability to react quickly. Kirk pointed out that the choice before us was not “no coordination” versus “mandatory UI that browsers must use”. Another better path is like international conventions for a stop sign from the 1920s and ‘30s – out of that came a set of recommendations like “If you want to use a stop sign, we recommend you use an octagon that’s red” of certain maximum and minimum dimensions – that’s all it is, a recommendation, and then it’s up to individual countries to decide whether to follow the recommendations or not. No one is suggesting a mandatory system where a rules comes out saying “everyone must make their browser UI look like this”. Instead, it would be great if the browsers came up with a set of recommendations, then it’s up to each browser to decide if it wanted to follow them or not, wanted to modify due to sudden changing circumstances. At least you would have established a recommended set of guidelines that browsers could follow if they chose to. Ryan asked Kirk if, given Adrienne’s mention of Chrome’s publication of research papers and a roadmap of Chrome’s future, including negative indicators for non-encrypted connections and no indicators for websites that are encrypted so the research, and the goal is to move to a neutral UI - did Kirk feel that on the path of these recommendations is not currently being met by the collaboration that browsers had in the W3C, within the informal communications within the published research, the accessibility guides? Did Kirk feel that was insufficient and there was a missing piece to all this – if so, what would Kirk like to see? When asked for clarification of his question, Ryan said Kirk mentioned a desire that recommendations come out and when there is already a substantial degree of coordination and collaboration between browsers and publication of research on this – it feels like Kirk is saying there’s something missing from all this, and it may be that what he wants is an agreement or decision on this. As the previous speakers said, the research is still ongoing to be able to make a recommendation – but it seems like there’s still something more that Kirk is wanting, that’s missing, and Ryan didn’t understand what it was. Kirk said he’d seen the Google research papers but those were just Google authors and one author from UC Berkeley – he was not aware that there was collaboration happening now among browsers on the UI. Gerv said he was sure the Mozilla team reads the Google papers because they are well authored and make good points about what a UI should be, and Gerv was happy to give Adrienne great credit for the scholarship of those papers. The other thing to keep in mind is technical capability – Mozilla recently produced a product called Firefox for iOS which uses the system APIs for determining whether a connection is secure or not, and he thinks there are many things about the SSL nature of the connection they can’t find out, and one of them may be EV status. So suppose there is a rule or suggestion that members of the Forum had to do something for EV, and people then said to Mozilla “your Firefox for iOS doesn’t display EV information” and we respond “well, we can’t” – what are you going to do? So there are various reasons why the UI of various products can’t conform with a suggested standard even if one was defined. And if the suggested standard has no “teeth”, if there’s no requirement, no sanction, no way of encouraging people to adopt it, Gerv was not sure what the value was in taking the time to define it. You define it, and then some more research comes out and you say we need to update this, and it’s a lot of work to update something that no one’s really paying attention to because their making their own decisions anyway. Mike said that was the challenge he had in trying to rack-and-stack this against some of the work on the technical solutions that the Edge, IE, and operating system teams are focused on. He uses Amazon like many people do and they’re not on an EV cert. Sometimes Mike is using different form factors that as Gerv mentioned, the indicator would never present itself anyway. He appreciates a lot of the transparency from the Google research as far as having that conversation – he knows the Microsoft teams are looking at that, and it’s helpful. Part of what he wanted to do was just have this conversation in the CA/Browser Forum out in the open and see where this is. Kirk asked the browsers if they thought users understood their current UI. Gerv said the answer was, the UI Mozilla has is the best UI they know how to make, but research is always ongoing and if we figure out how to make it better we’ll make it better. If Mozilla knew how to make it better right now, Mozilla would probably do it. Kirk suggested that if browsers thought users didn’t understand the current UI, maybe browsers should just get rid of their UI entirely. Ryan said that is on Google’s roadmap – to remove a substantial part of this UI, and Google is clear and public about that, as well as Google’s transition plans for removing a lot of that UI. But there is a different question that Mike touched on, which is whether the CA/Browser Forum is the best place to solve that, and he thinks that for Apple, Microsoft, Google – the CAB Forum representatives from the browsers are not the people who will be making that decision. Each browser has a different set of constituents and participants. Google was lucky to grab several of the UI experts on the call today, but even there it may not be obvious but these experts work with the UI team to make these decisions. They do an amazing amount of research on exploring the best way to communicate things and there’s a process of UI review that goes through for Chrome changes. So if the question is, is the Forum the best place to solve that, Ryan doesn’t think this is the right place or the right venue, and it may not be that CAs are the right or necessary participants in this discussion. Ryan knows that’s a controversial one and will leave that hanging out there, but we do collaborate very extensively because we all share a common goal, which is to see better security of our users. Google has a particular goal on that and is moving towards that goal in collaboration and also on research. The Forum is probably not the best venue for that, even if there was an opportunity. Kirk asked if others agreed, disagreed, or had other comments. Mike said he tended to agree with Ryan’s comments. He posed the question, but he didn’t think the CAB Forum was the right forum to do this but wanted to have the conversation. Kirk asked if Mike had other forums in mind for collaboration. Mike said he knows in W3C it’s been brought up in the past, but apparently didn’t get very far. Mike said he wasn’t directly involved, there are different parts of Microsoft that are focused on UI and how we think about it from security. He assumes the appropriate forums are W3C and maybe other forums. Ryan said there are a number of venues where these conversations happen, including the W3C and contacts established between the teams working on the standards and the UI teams, both informal and formal collaboration on those UIs as it relates to permissions and security indicators on different platforms. This tends to be something that is very browser specific and not involve the core platform team. And then there’s informal sort of things in terms of the research conferences, things like SOUPS [Symposium on Usable Privacy and Security https://www.usenix.org/conference/soups2017], etc. where some of this research is presented on usable security UIs. Then you find teams working on accessibility, on the implementation of this collaborating informally at these research conferences. So there’s a variety of venues that happen; whether or not there needs to be something formal is an open question. But within the browser community generally everyone knows who their respective counterpart is or makes introductions for that for a lot of these – what is the research saying, where is the roadmap, and we tried to be very public about ours, with the research Emily did. Kirk asked if it was possible if this could be done in a more public and transparent way where CAs could participate. Ryan said he thought it would be fantastic if CAs wanted to start contributing research to symposiums like SOUPS or W3C – that would be a welcome contribution. The important thing is a lot of these decisions are being made in a product-specific way, and so a CA is just another customer, one of many, or they are being done based on empirical-driven research and anyone who has useful contributions is more than welcome to collaborate. Kirk noted that CAs’ customers [website owners] are not very happy with the current status of browser UIs and they are a primary party in this. Research is one thing, but being able to talk to each other in a public way is probably more effective. If collaboration among browsers is already happening, we’re not aware of it and we don’t feel we have the ability to make input, so if there’s a way you can open it up so that everyone can participate transparently, that would be really appreciated. Ryan noted that the W3C and SOUPS are open forums. Kirk asked which group at W3C Ryan was referring to. Ryan said he would follow up with Kirk after the call, but in W3C there is the web incubator community that allows for collaboration, the Web App Security Group that discussed heavily around permissions. For all the reasons Ryan has talked about, these are product-driven decisions, branding decisions that affect the respective products. There’s a collaboration on principles, but there’s not going to be a direct collaboration on UI – Ryan said that’s what Kirk may be looking for and is not going to find, but if there’s useful contribution in the academic literature that suggests changes to the UI – those would be fantastic things to share. Kirk asked Mike and Curt if this was the discussion they had wanted to have. Curt said yes, and said he agreed that standards are kind of nice, but they might tie some hands, and in any case he was not the right person to make decisions on his side (for Apple). Kirk noted that several browsers have said that, and asked if it would help to bring in the right people for this discussion, the people who actually do make those decisions. Mike said he thought this was a good conversation to have, and that the forums that Ryan was talking about like W3C and SOUPS conferences are probably the appropriate forums, and that he could connect with the Microsoft folks that go influence those conferences from a UI perspective. This has been a good conversation from his perspective. As to the specific questions he had, like should we add a working group or get into specific solutions on some of these issues, it doesn’t feel like the CAB Forum is the appropriate forum to do that. Kirk said that it did sound that there actually is no forum right now that is specifically looking at trying to create a common UI or some commonality in the UI among browsers, which was a shame. He said he thought it would be great if that actually would start to occur somewhere, he didn’t care where that occurred. Mike said part of what he was trying to get across was maybe the common browser UI was not the solution – it might be part of it, but there’s more technical solutions versus the user training and UI solutions that are probably being worked on. Kirk pointed out that these two were not mutually exclusive and they should both be going forward in his opinion with both protective things for users that happen behind the scenes, but also he comes back to what good is a UI if nobody really understands what it’s supposed to mean, which is the current status right now. He’s heard Google say its planning to do away with the UI and just rely on the other protective measures which certainly is one approach but a browser could actually employ both and get some benefit from using both, a UI that users understood and then all the other methods as well. Adrienne said it sounded like there were two separate questions – one is do users understand the UI, and the second is do we want to achieve consistency. She doesn’t know if consistency will solve the first problem of confusion. If one browser had the perfect UI that solved the comprehension problem then we might be in a space where we could say ok, let’s all move to that. But just speaking for herself, Adrienne said she didn’t think we have reached a fixed point where we can say ok, this is the right UI, let’s all now move to this. She doesn’t think it makes sense to do commonality until we are there, consistency just for the sake of consistency not necessarily useful. Kirk said he agreed completely, he just thinks it would be great if there were discussions happening among the browsers to see if they can agree on a common UI that is useful. Mike said that to Ryan’s point it’s not the common UI, the challenge is the safety and security of our end users, things like phishing and man-in-the-middle, whatever – that’s what we’re trying to solve, everyone on the call is part of trying to solve those issues. The browser UI is not the problem we’re trying to solve, it’s the underlying problem of things that have been brought up like phishing sites. We’re just trying to protect our users, that’s all we’re trying to do, and a common browser UI may or may not be the best use of resources to solve the problem. Dean said he thought something should be looked at because his fear is that we’ve already heard the EU Commission getting involved in eIDAS certificates – what’s to prevent them from doing the next thing which is coming back and saying “oh, this whole browser UI thing is a mess, we need to get involved here and put some standards around that”, and if that happens I think that’s actually a worse outcome. So it behooves the community to try to do something without having that type of heavy handed regulation. Gerv said if that’s going to be a worse outcome it would seem you wouldn’t be responsible for any lobbying effort trying to persuade governments to head in that direction, then. He agreed that’s a worse outcome and is hoping that doesn’t happen, but he’s never heard of any government intervening to mandate the user interface of a software product, so it’s reasonably unlikely. Dean said you have heard of governments intervening to standardizing security types of things like stop signs, or something like that. Kirk said the time for this subject was up, but did note that CAs have posted research on this subject on the CASC site [www.casecurity.org/identity<http://www.casecurity.org/identity>] that shows that there’s virtually no phishing, fraud, or malware at identity sites (OV and EV cert sites), and we thought that some use could be made of that – it’s not being used, but 25% of websites today have OV and EV certs and they don’t have phishing or fraud. It seems like an innovative browser could make use of that in the UI, but he will leave that alone. Kirk asked for other comments on the topic, but there were none. 11. Ballot Status - Discussion of ballots (See Ballot Status table at end of Agenda). Peter noted that Ballot 202 was in the voting period now. He reviewed its contents, and asked for members to cast their votes. 12. Any Other Business. Dean noted that Li-Chun had posted additional information on the Taipei meeting in October, and asked members to register by adding their names to the wiki now if they planned to attend and to make hotel reservations as soon as possible. 13. Next call August 3, 2017 14. Adjourn
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
