2014-05-29 Minutes
Notes of Teleconference – CABF – 29 May 2014
1. Antitrust Statement: Read by Ben.
2. Agenda was reviewed.
3. Roll Call: Ryan Sleevi, Ben Wilson, Atsushi Inaba, Moudrick Dadashov, Rick Andrews, Atilla Biler, Kirk Hall, Mert Ozarar, Dean Coclin, Jeremy Rowley, Marcelo Silva, Cecilia Kam, Doug Beattie, Joe Kaluzny, Robin Alden, Kelvin Yiu, Geoff Keating, Rich Smith, Stephen Davidson,
4. Minutes of teleconference of 15-May-2014 were approved.
5. Ballot review: Voting on Ballot 120 (Affiliate Approval of Domain) and Ballot 124 (Business Entity Clarification) ends Thursday, June 5, 2014, at 2200 UTC.
Rick reminded everyone about Ballot 125 for CAA and noted that nobody else has followed up by email. He asked whether he should try to get a more vigorous response, or to submit the ballot for voting to elicit more discussion. Ben noted that Rick had recommended that people look at the standard and also that the minutes from the last call contain the pro and con arguments. Rick said he hadn’t seen the minutes, but that it seemed like the debate was not about the ballot itself, but about CAA in general, with one side saying it would have an anti-competitive effect. If the ballot needs two endorsers, Ryan said he would happily endorse it. Jeremy said that DigiCert may have endorsed it as well, but that he needed to check.
6. Application of Camerfirma: Dean said that they had signed the IPR and submitted links to their audit seal. Ben noted that they had been a CA member before, and that they just dropped off when they hadn’t submitted the IPR Agreement, so there should not be an issue with re-admitting them. It was recommended that Dean correspond with them and let them know that their application is approved.
7. Discussion: Root Programs – Browser point of view / commentary on root programs in response to emails from Mert and Atilla of Turktrust
Kelvin: Microsoft does not have an open process, but Turktrust has been listed as a CA, so they do not have a specific response.
Turktrust: The uncertainty and delays in the process are serious problems for us. Communicating with Oracle has been a specifically difficult process. It is hard for us to know the schedule of when we will have a root included, and with Apple and Google for EV enablement in their mobile devices. We would like more insight into the release schedules. For instance, with Android, the root store has to be updated, but we don’t know when the next version of Android will be released. And then phone vendors have further control over the upgrading of their devices. This is a problem not just for Turktrust, but also for other CAs throughout the world.
Ryan: As a matter of policy, Google does not commit to specific release dates. The first step is to submit the root on the bug list and request inclusion in the bug tracker.
Rick: You point to when a root will be included a particular version, but not the timing of when that version will be released.
Atilla: What about EV enablement, so we can manage expectations – internally and for customers?
Ryan: The discussion needs to take place on the bugtracker.
Geoff: As a general principle, you can always ask Apple. You will be told once you’ve been approved. It will occur in the next update, but we don’t announce when that will be.
Kirk: Oracle has an email address that I can provide to you after the call.
** 8. Discussion: Processes used by CAs for DV validation** of Domain Name registration/control:
Ryan: The CAA discussion a few weeks ago sparked internal discussions about the variety of procedures that CAs use to perform domain validation, and that while it is good to have some flexibility in the processes used, there is concern about methods 6 and 7 in the Baseline Requirements. Method 6 is “making a pre-agreed change” and Method 7 is “any other method” (which is not allowed under EV), and which may need to be amended by a ballot. We are concerned that CAs not implement processes that only involve trivial modifications to server files. We do not want validation of domain ownership to involve changes that are easily made on public files of servers. We would like to restrict the kinds of files that can be modified and we’re hoping to get an understanding from CAs on the kind of file changes that we should expect to see from domain validation processes.
Jeremy: Digicert has not used this method, or if it has, it has been very minimal.
Robin: Comodo uses this method. We specify the filename which must be detected and we generate a name using a hash tied to the certificate request, and the location and the content have to be specified by us and must be put in place by the applicant.
Rick: I think Symantec uses something similar.
Ryan: It is my understanding that a good CA would generate a random file name and file content in a way that is more difficult for an attacker to do. We would want to tie some of this to the rights held by a domain master, and not public users, for a strong set of ownership / control measures. One of the suggestions may be the well-known uri, with a CA’s challenge protocol, but require a filepath that is well-known and not open to end users so that a requester cannot influence the location or content.
Rick said he thought this solution might be ok, but he would like to talk internally about it. Robin agreed.
Ryan: We should also consider whether to still allow this method for wildcard certificates. There a may be situations where an applicant could demonstrate control over the path, but that might not establish domain owner awareness. The idea would be to restrict wildcard issuance to methods that demonstrate full domain control.
There are issues, for example, where the server operator is different than the registrant. This one of the questions that we had on CAA.
Ben: Where we might want to use the demonstration process is if it’s a device, and not a web server, but there are only a limited number of file locations where they can make those changes.
Ryan: That’s a concern. It starts to get into the social engineering level. A server operator might not have an understanding of how to protect against access, and it is hard for the CA to determine whether a device compromise has occurred.
Ben: There may be ways to compensate, but still allow it-for instance, if the CA has other mechanisms in place to prevent this kind of social engineering, like if it were coupled with CAA–the customer is going to know and express which CAs it trusts for its domain. Once we have CAA somewhere listed in the BRs, then we can say that you can do this if you have a CAA record. The goal from this ongoing discussion will be to try to find ways to mitigate that.
Ryan: The next step is for us to decide how to proceed. We already have an idea of what a draft ballot would look like.
Ben: We keep this on the open-items list of things to resolve. We can continue to discuss this on the public list as we fine-tune it, and then we can move forward publicly.
** 9. Next Face-to-Face Meeting:** Agenda will be coming out soon.
** 10. Working Group Updates:** Jeremy: The EV WG has two ballots pending and a few more in the wings. The two ballots right now are not major changes, the next ones are more significant, but not major either. Dean: For code signing, we had a meeting last week. We are finalizing the draft, and we hope to have it finalized for our face-to-face meeting. Then we’ll want to have a draft published so we can get it out to for CAB Forum review and then to software providers for them to review. Ben: The SSL Performance working group is continuing its discussions on certificate size.
** 11. Next phone call** will be Thursday, June 12.