Final Minutes for CA/Browser Forum Teleconference – January 25, 2018 Attendees: Arno Fiedler (D-TRUST), Atsushi Inaba (GlobalSign), Ben Wilson (DigiCert), Cecelia Kam (GlobalSign); Corey Bonnell (Trustwave),Curt Spann (Apple), Daymion Reynolds (GoDaddy), Dean Coclin (DigiCert), Devon O’Brien (Google), Doug Beattie (GlobalSign), Enrico Entschew (D-TRUST), Frank Corday (Trustwave), Gervase Markham (Mozilla), Jeff Ward (BDO - WebTrust), Jos Purvis (Cisco), Kirk Hall (Entrust), Li-Chun Chen (Chunghwa Telecom), Mads Henriksveen (BuyPass), Michele Coon (OATI), Mike Reilly (Microsoft), Neil Dunbar (Trustcor), Patrick Tronnier (OATI), Peter Bowen (Amazon), Phillip Hallam-Baker (Comodo Security Services), Rick Andrews (DigiCert), Robin Alden (ComodoCA), Ryan Sleevi (Google), Shelley Brewer (DigiCert),Sissel Hoel, (Buypass), Tim Hollebeek (DigiCert), Virginia Fournier (Apple), Wayne Thayer (Mozilla), Xiu Lei, GDCA.
1. Roll Call 2. Read Antitrust Statement 3. Review Agenda. Agenda was approved. 4. Approval of Minutes from teleconference of Jan. 11, 2017. The Minutes with corrections of one typographical error were approved and will be posted to the Public list. The Minutes for the Taipei Face-to-Face Meeting of Oct. 4-5, 2017 were automatically approved on Dec. 27, 2017 under Bylaw 5.1(a) and were posted to the Public list on Dec. 29, 2017. 5. Governance Change Working Group update. Ben said the WG had considered various comments on the last draft, and would change the duration of the new Web Server WG to be perpetual in the Bylaws and charter. He covered other details still under discussion. The WG has specified that new Working Groups may create Subcommittees to function like current Forum WGs. Virginia noted that with respect to new Working Groups being perpetual, W3C has had a problem with some of its committees being perpetual after their work was done – there needs to be rules and a mechanism for terminating a new Working Group. Gerv agreed, noting that the new Working Groups were essentially autonomous, and that the Forum as a whole needed some means to shut down a Working Group if necessary. Ben said in most cases a termination date would likely be included in the original charter creating the new Working Group, but perhaps the Bylaws should also include an option for termination. Tim said he thought only the new Web Server Working Group should be perpetual. Based on this, Virginia said Ballot 206 will need additional language allowing Working Group termination and allowing subcommittees. We also need to clarify that two new Working Groups can share information on what they are doing (to help coordination where there is overlap), but we need to think through how that affects IPR issues (as each new Working Group is only liable to IPR requirements for its own work). This probably won’t be a problem as Working Groups are mainly likely to share finished product. Dean said that overall, the comments received indicate that members are reviewing the Ballot 206 draft materials, but the WG has to go back and do further work. The project is worthwhile. Virginia added that the bad news is it’s been over a year, and it’s taking longer than anticipated. Kirk asked if the changes to the IPR Agreement would solve the problem identified for Interested Parties (who arguably aren’t “Participants” at present, and so may not be subject to the IPR Agreement even though they sign it), and Virginia said yes. Wayne asked for a clarification – when Subcommittees are created, will the existing Forum Working Groups automatically become corresponding Subcommittees of the Server Certificate Working Group, and continue as today? Tim said yes, and Gerv said that was covered by the ballot language. Virginia said this will be further clarified. 6. Policy Review Working Group update. Ben said that on the last WG call, they replaced the term “Issuing CA” with “Parent CA” to avoid including CAs that issue end-entity certificates. The WG will start on Section 6 of the BRs today. Ryan asked if there was a link to the current draft of the document, and was concerned that using a term like “Parent CA” could be confusing where there is a complex structure. Ben said the draft is on GitHub, and he will provide a link. 7. Network Security Working Group update. Ben said the WG was working on Section 2(g) of the Network Security guidelines concerning multifactor authentication for all accounts outside the defined security zones – this will be taken out of Section 2(g) and added to a new section of its own. The WG is editing the user name and password requirements now – it tried to follow NIST SP 800-63, but that’s proving to be hard. 8. Validation Working Group update. Tim listed the issues being worked on: (a) Possible amendment to RFC 6844 where CAA record sets exist without proper tags (this will also be pursued at IETF), (b) TLS SSI – Requirement 10, (c) EV validation method improvements, (d) BR 3.2.2.4.1, and amendments suggested by Mads, (e) IP address validation under the BRs, and getting rid of the “any other method” language, and (f) account tags for CAA if you want to add account information after your issue record. 9. Ballot Status - Discussion of ballots (See Ballot Status table at end of Agenda). Ryan said that for Ballot 218 on deprecation of BR 3.2.2.4.1 and .5, Google was a ballot co-sponsor for the August date for implementation, and while that might be acceptable date for the Forum to agree on, Google doesn’t think that’s in the interest of the security ecosystem, and would rather see a much sooner date for the cessation of those methods. So to be clear, the endorsement of Ballot 218 is not because Google believes August is a reasonable date, but it is in the CAB Forum document, and Google will be reaching out and taking mitigation measures to protect users from CAs that use Methods 1 and 5. Kirk asked Ryan what kinds of mitigation measures Google had in mind. Ryan said that was not for the CAB Forum at this time, but said Google was investigating all possible mitigations as appropriate to keep users safe. Curt said to make the timeline clear, would those mitigations come before the August implementation date? Ryan said yes. Curt asked if Ryan had a time when they would be introduced. Ryan responded that Google was very curious to see how Ballot 218 goes, and the mitigations could be introduced even into Chrome’s current pending branches as soon as, say, Chrome 65 scheduled to be released very soon. Ryan said he did want to stress Google’s view that the March date for that cessation is realistically what they think is aligned with the security properties and concerns about the level of discussion provided by CAs and members regarding their use of the methods, and will be exploring solutions for that as well. Kirk asked if Google is going to move forward and deprecate Methods 1 and 5 on its own, why do we even have a ballot. Ryan responded, why do we do anything in the CAB Forum – because we can recognize there’s remit in the Baseline Requirements, and the thing with SHA-1 – Google took steps to protect users. Google’s commitment first and foremost is the security of Google users and we’re interested in cross-vendor solutions. But when faced with validation methods that provide insufficient levels of control and assertions for domains Google will take steps to ensure that the integrity of users’ browsing activity is protected, and in that context BR 3.2.2.4.1 and .5 do not meet the level necessary to have a safe and reliable browsing experience. Kirk asked Ryan if Google was aware of any misissuance of certificates under Method 1. Ryan said that is a question that is probably more complex than can be covered on this call given our time limits. Kirk asked Ryan just to give the members a summary, as we were actually ahead of schedule and had the time – has Google found any misissuance? Ryan responded by posing a question – this represents a fundamental disagreement: if you don’t validate a domain name and it just happens that the person who is currently running that domain name gets the cert, is that a misissuance? In Google’s view, yes, because the process did not actually validate control over that domain, it did not validate the authorization of that request. If you have a method that allows potentially an unauthorized party to obtain certificates, yes, our view is that is misissuance. The problem with that framing Google continues to disagree with – the assumption that “if no one detects it, is it misissuance,” is a fundamentally flawed premise. The question is, was the cert issued in a way that provides a consistent level of assurance – if it was not, that is a problem. Peter said that’s one view, but said to the Forum members, he doesn’t think we know today whether misissuance has occurred. Probably every CA reasonably has at some point received an email from a company saying “this certificate was issued and we don’t believe it should have been”, right? Kirk responded that to his knowledge, Entrust had never received a message like that from a customer. Peter asked Kirk, you’ve never received an email from some employee of a company received a cert that some other employee of the company thought they shouldn’t get? Kirk confirmed that was correct – part of the reason was that, as is says in BR 3.2.5, CAs must give customers an ability to designate who in their companies can order certs, and who cannot. Kirk has actually been wondering how other CAs are complying with that requirement for some of the automated domain control methods – maybe they are not complying with that section. Kirk raised the “control versus ownership” issue – when someone is getting a certificate by proving “control”, nobody has any idea who that is – it might be the DNS provider, it might be an ISP or hosting company, it could be a rogue employee for either of those companies. The idea that “somebody” (you have no idea who it is) proved “control” over a domain does not mean that it’s an authorized cert – it could be a misissued cert. Kirk was very puzzled about this conversation. Ryan said he wanted to argue that that was exactly what Google wanted from the web PKI, it is not a misissued certificate – that in fact is the ideal state and any other method that does not provide that level of assurance is insufficient – that’s the heart of the disagreement. Curt asked Ryan if the point was if you can prove control of the domain and get a cert issued then you can also change the content of the domain, or whatever, so for all intents and purposes you control that endpoint. Kirk said you might have been a hacker. Peter said this really goes back to the question of what is being certified and what is therefore an appropriate thing. He continued that the comment he had made – before he dealt with CAs running one, he was a customer of CAs and there were various times when he had gone and gotten an OV cert from several different CAs when he’s been an employee of a company – that’s a pretty straightforward thing. And the question then comes down to, great, now that we have CT what we’re seeing is that companies are identifying certificates that their central security department was unaware were issued. Does that mean that the validation failed? Absolutely not. In fact in many cases what Amazon has seen at least is that the answer is “Oh, right, sorry about that, we forgot that this host name was handed off to Marketing, and they got a cert to put up the new Event website, great.” But we get the emails fairly often where one part of a company is unaware of what another part of a company is doing. Kirk asked if those were DV certs, typically. Jos said that Cisco has dealt with quite a few of those, and they were mostly OV certs, and in a few cases they were DV certs, but in some cases they are OV certs. Peter added that all the validation was 100 percent correct – the company is not arguing that it was improper or a misissuance under the rules, the company was called, it was verified that it is an employee of the company, active, that they were able to prove control, they even have DNS control – but there is some other arm of the company that just wasn’t aware and is monitoring all certs. That’s why Peter is saying he assumed this was a pretty common issue when you have very large company customers because these are huge companies. You talk to somebody like General Electric, the lighting and appliances divisions know nothing about each other, or the nuclear reactor division. I wouldn’t call those misissuances, but the core question is “what is being certified.” Peter said it sounded like there’s one view which is it only should be that every company should designate a group that is authorized to get certificates and anything they say is good – that that is what we are trying to certify. Another view is a CA is certifying that as of this point in time there was technical control over the domain by the applicant. Kirk added “whoever that person might be” – he might be with the company, or not, a hacker, a rogue employee. Peter agreed, that is what the CA is certifying. Kirk questioned whether that was more secure for users - Kirk didn’t share that view. Peter said he wanted to finish his prior sentence – he wasn’t saying yes or not to that, instead he was saying one of the core things the Forum had to do was answer that question of “are these appropriate validation methods, what are appropriate, what are CAs supposed to be certifying.” Kirk responded “ownership or control.” Peter said when you get a driver’s license, it certifies that you have passed a driving exam and you have done a certain thing. Kirk interjected that you have also proved that you are Peter Bowen, and Peter agreed. But Peter said the question is, what are CAs supposed to be certifying here, especially in a world of legal entities as opposed to natural persons, that is OV, you can’t certify that somebody is amazon.com. Kirk agreed, but said a CA can take steps to ensure it’s someone associated with amazon.com who’s getting a certificate under Method 1. Peter agreed. Kirk said you can’t prove anything with Methods 2-10, you have no idea who that person is, or if they have authority or no authority – they just have control. Peter said that’s why we have different types of certificates – we call them individual, organization, and domain. Peter said that what Kirk just said – “ownership or control” is one answer. Kirk said that’s what it says in BR 3.2.2.4 right now, so this is quite a change from what we’ve done. Peter said that’s what he’s saying, we need to sort out to answer what are appropriate validation methods – there needs to be a clear statement of “this certificate certifies X”. Kirk said it sounds like the only problem we are addressing by getting rid of Method 1 is that some person within a company surprises someone else within a company who says, “well, that person really shouldn’t have ordered a cert”, and Kirk didn’t see that as a valid ground for removing a validation method where there’s been no actual misissuance demonstrated ever. Peter said he was not sure how you would prove there was misissuance through that method, but Peter said he thinks there has been solid demonstration that Method 1 today does not provide proof of technical control of the domain, he thinks everybody agrees with that statement, so the question is, does it provide proof of ownership of the domain – that’s really the core question here. Kirk agreed. Peter said the same is true for BR 3.2.2.5 on certs for IP addresses – you might be able to separate the validation methods into validation of technical control of domains and validation of ownership of domains, and look at each one within those categories and say does it meet that bar. Wayne asked if the question here was whether BR 3.2.2.4.1 meets the definition of ownership of the domain, or whether we want to allow ownership to be a permitted approach to validation domain control. Tim said that’s an important point because people have been confused about this – if you look at Ballot 218 the ballot does not say that ownership is not a valid method of validating a certificate. The reason is, look at Method 12 – it verifies ownership. That method is added in Ballot 218 – so it’s not true that the ballot is going to a model where you’re only allowed to validate technical control. Tim said the issue that Ballot 218 is trying to fix is that if you’re validating ownership, it is important that ownership actually be validated with a sufficient level of rigor. Kirk mentioned that control doesn’t show ownership at all as we know, you could be an ISP/hosting company or DNS operator. Peter agreed, and said it goes back to what is being certified. Ryan said Google’s view is that the minimum level for all certificates should be some demonstration of control – Ryan would quibble with Tim’s point as to how ownership is being demonstrated but would also assert that control is being demonstrated in what is allowed by Method 12. A domain validated certificate – the expectation from Google on what constitutes a secure site versus a not secure site, minimally is with control, demonstrated control at a suitable level. Additional certificate types exist to demonstrate additional facts such as organization validated demonstrating the notion of ownership, and EV nominally building on that, but the minimum basis of all this is a foundation based upon control. If an entity which does not control a domain can issue a certificate, our view is that is misissuance. The debate with BR 3.2.2.4.1 is, if you have two employees at the same company, has control been demonstrated, and the assertion Ryan is making again is that control has not been demonstrated - the authorization, however you want to phrase that, has not been demonstrated so it’s not sufficient. Method 12 resolved that by only allowing those entities that have the technical control to be able to demonstrate that level of ownership - that is an assurance. Methods 2 and 3 exist to bind that goal to the notational idea of ownership. The consistent minimum level is that control needs to be demonstrated – that’s Google’s expectation. Other types of certificates are there to make other types of assertions to build on that, for whatever value that may be, but when a user connects to a secure site, an https site, that the party who has that private key must have demonstrated control during the lifetime of that certificate. Wayne said that what Ryan was suggesting is that in BR 3.2.2.4, where it says you have to validate ownership or control, the “ownership or” piece should be struck, and from now on BR 3.2.2.4 should say “only validate control.” Gerv said that was not necessarily the case because there is the converse situation – if you are the owner of a domain, you may not want your DNS operator having the ability to get certificates on your behalf, you may not want that. You may want your CA to demonstrate in some way both ownership and control before they issue the certificate to anyone. So Gerv didn’t think the concept of demonstrating ownership was necessarily completely abandoned, but Ryan may be making the case that you either demonstrate control, or you demonstrate control and ownership. There may be a future world where you can use a CAA record to define which methods you like and which methods you think are insecure – you may want to restrict it to methods which require proof of ownership to prevent short term hacks of your infrastructure leading to loss of control of certificates for your domain. Peter said one of the things we need to be careful with is that there are other methods that haven’t been in discussion that maybe need to be if this is the path we’re going because BR 3.2.2.4.4 or .5 – constructed email – definitely does not show technical control. There’s very limited proof that emailing “postmaster@domain” proves any sort of technical control of the domain. There’s a lot of good reasons that gets used, but we need to be careful that similar to the discussion on Method 1 we know what is being certified and make sure that the methods align with that. Historically we’ve had a set of “ors” you are certifying that “A” or “B” or “C”, and if we’re going to start talking about changing that, we’re going to have to examine a lot of this. Ryan agreed, and said this is the same concern that Google and Microsoft have raised in the past with Method 6 [posting agreed content on a website] because of the question about the level of assurance about what you’re certifying versus what the certificate is viewed as representing from the browser side. This is the heart of the question for all validation methods. 10. Maintaining Forum documents and website. Ryan said that the current version of Forum documents were out of date, as was the website, and said the Chair was responsible for staying current on this. Kirk said he would work with Ben on this issue. Dean asked for volunteers to help maintaining documents and the website. 11. Logistics for March 6-8, 2018 F2F meeting – Amazon, Herndon, VA. Peter said he had posted hotel information for the meeting on the wiki, and asked people who were coming to add their names to the list. Dean announced the meeting would include as a guest speaker Rep. Jim Langevin (D-RI) who is on the House Armed Services Committee and Homeland Security Committee, and takes an interest in cybersecurity matters – it should be an interesting talk. 12. Possible Topics for March F2F meeting. There was no time for this topic. 13. Any Other Business. There was no other business. 14. Next call: February 8, 2018 at 11:00 am Eastern Time 15. Adjourn
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
