2013-01-10 Minutes
Notes of meeting
CAB Forum
10 January 2013
Present: Maarten Van Horenbeeck, Stephen McHenry, Atsushi Inaba, Ryan Koski, Gerv Markham, Brad Hill, Dean Coclin, Rick Andrews, Robin Alden, Mert Ozarar, Atilla Biler, Cagdas Funda, Jeremy Rowley, Eddy Nigg, Sissel Hoel, Ryan Sleevi, Steve Roylance, and Kirk Hall.
Agenda Review: the agenda was reviewed and Ben mentioned that Phill Hallam-Baker had contacted him previously to make sure that CAA was discussed, and he thought it could occur later after the discussion of Turktrust. Phill was not on the call, but joined near the end of the call, and we discussed CAA under Item 9. Other Business.
Approve Minutes of 6 December 2012: The minutes of 6 December 2012 were approved as published.
OCSP AIA requirement (Remaining BR Issue 7)
Ben said that we need to wrap up the correction needed on BR Issue 7 (Mistake in Exhibit B - Stapling is not an exception to having the OCSP AIA in a certificate)
- WebTrust / ETSI Audit Implementation Cycles
Dean said that we need to coordinate better on implementation timeframes and auditability. A working group was formed to hammer-out the details. Members of the working group are Don Sheehy, Iñigo Barreira, Dean Coclin, Kirk Hall, a representative of Google (TBD), Kelvin Yiu/Tom Albertson, Gerv Markham, and Jeremy Rowley. The objective/goal of the working group will be to come back to the group as a whole with a recommendation of how coordination among document revision cycles for requirements, audit criteria, auditing, and browser compliance should work.
- Discussion of TURKTRUST facts
Mert and Atilla presented the facts of the Turktrust-issued certificate to EGO that had CA=True. Atilla explained that they had provided an update on their web site and via email. The event occurred on August 8, 2011, prior to / during preparation for audit certification. Since November 2011 Turktrust has been compliant with ETSI audit requirements. Then in December 2012 they discovered the faulty certificate, and have now improved their existing Change Management procedures. The post-issuance logs examine certificate contents and extensions. These are checked by an internal audit process. He also said that they have also discussed the case with their KPMG-BSI auditors who will perform an additional limited scope audit for change management, incident management, and internal audit processes.
Ben asked about the Checkpoint Firewall issue and whether other certificates besides the one issued to Google had been discovered. Atilla recounted that the Google certificate was detected by Google, but he has no further information about any detection or usage of any other certificate out of the EGO domain.
Rick Andrews asked about Turktrust’s plans to implement the Baseline Requirements and the Network and Certificate System Security Requirements. Atilla said that ETSI requirements for networking security have all been implemented and the Baseline Requirements that are referenced in the final ETSI standard are implemented and audited by their auditors. Rick noted that the current Turktrust CPS did not mention the “Baseline Requirements.” Atilla said they hadn’t yet declared conformance to the Baseline Requirements, but they will declare at some point. They have had discussions with KPMG-BSI Netherlands, their ETSI auditors, and they will first comply with ETSI audit requirements and then CABF Baseline Requirements.
Stephen McHenry asked what procedures Turktrust had in place to detect whether any subCA certificates had/have been issued. Mert said that they had checked the audit logs for any certificates with those CA=true condition, and the only two certificates they found were the EGO one (ego.gov.tr) and one to e-islem.kktcmerkezbankasi.org. In addition to the existing controls coming from ETSI requirements, currently Turktrust has implemented an independent post-process control and a runtime control that runs live. The post-process control can additionally be run as a chron job to review such fields as BasicConstraints, AIAs, and the pathlengths of subCAs. Stephen asked how quickly are they detected after issuance, assuming that somehow the certificates make it past the current controls due to software errors, runtime errors, or whatever-to detect the situation after it has occurred. Mert said that they had previously explained how the misuse of the profiles had originally caused the problem and that if the runtime controls do not prevent a certificate from making it to the database the scan can be run on demand through the certificate database as a completely independent process that checks the certificates. Stephen said that Turktrust should run the process routinely because software errors do happen. Mert agreed and said they would run the process as a chron job periodically, but that he believed that they already run it daily already.
- Discussion of preventative / remedial measures
Ben asked for discussion on additional preventative or remedial measures.
Jeremy said that he was working on an additional set of CA controls, such as developmental controls, because we already said during adoption of the Baseline Requirements and Network Security Requirements that we were going to come back and address some of the issues raised by the Diginotar situation later. He said he hoped to have a draft out soon and that volunteers were welcome. Robin said he would help.
Rick asked whether Turktrust only issued certificates to Turkey, and if so, then Name Constraints might be used as a preventative measure? Atilla said that they do not issue any certificates in the US so far, but that doesn’t tell the whole story because they issue certificates to .com domains and to many sites all around the world that have physical locations and data centers within the United States. Atilla said that therefore a name constraint of .tr would not work, because there would be too many negative effects.
Maarten asked if anyone knew whether the EGO subCA certificate was installed on the Checkpoint Firewall intentionally to inspect traffic. Atilla said that he does not know because it happened at a customer site. What we do know is that at one point it was installed on a server and was detected by Chrome. The assumption is that the firewall was intended to inspect traffic, but he is not sure whether EGO or Checkpoint Turkey will release any announcements or final reports, but that hopefully they will.
Eddy suggested that we scan certificate databases at EFF and elsewhere for certificates on SSL servers where CA=true and other similar criteria. Ben suggested that Eddy write a note to EFF, Ivan Ristic, Yngve Pettersen, and Bernhard Amann at Berkeley to see if they are interested in running such scans, even if only for academic reasons or out of curiosity.
- Logistics of next face-to-face meeting
Gerv said that they are expecting at least 24 people and there will be enough seats, but any one arriving beyond that number might anticipate standing or sitting along the wall.
- Any Other Business
Ben asked about involvement of invited experts like Yngve who sign the IPR Agreement. They have posting privileges on the public list, but what about their ongoing allowed participation? While it depends on each proposal, for instance with the revocation group, those who have signed the IPR Agreement should be able to participate. Dean said he thought it was a good idea to improve the rules in this area. Kirk noted that while we have observer status for entities like WebTrust, ETSI, and PayPal, but that there are plenty of people in the world who might qualify as experts and that allowing participation just on that alone won’t work and we do allow them to participate in working groups-so he would oppose opening up greater participation in meetings and regular phone calls to that category. Kirk said he was open to working with Dean on this issue. Ben said that the working group is one approach to segregating discussions off from the main group, but the other approach is to have very stringent rules on which experts will be invited or qualified to participate as invited experts. With the first approach we’d have to make sure that there is a working group in which someone interested could participate, with the second approach we’d have to decide what the qualification steps and voting percentage would be to approve someone as a permanent invited expert. There would have to be sufficient rules around the latter approach so that we would not be accused of being too exclusionary. Jeremy said if all of the discussion took place on the public list, the only thing that such individuals would not have would be voting rights. Ben noted that they would get to participate in live discussions. Kirk said that where we determine that an individual has enough expertise we could invite them to speak as a guest. Ben agreed.
Phill joined the call and those who stayed on continued with a discussion of the CAA record proposal. Phill said he’d like to put forward a proposal that CAA be required. Rick said that there are several solutions that have been proposed and he wondered if we mandated CAA whether people would stop looking at the alternatives or whether they would implement “all of the above” or what. Phill said that CAA does something that nothing else does, which is it allows companies to say, “do not issue certificates for my domain unless you’re one of my approved CAs.” Everything else, CT and DANE, are looking at either client enforcement or detecting anomalies and reporting them. Because CAA is different than CT or DANE, adopting one solution does not exclude the other. Ben noted that during our December call we discussed using the word “should” rather than “shall” except when necessary to mandate a global solution. Phill said that CAA only requires that you look at the CAA record, nothing other than that. Ben said he understood Phill’s position on how CAA would be implemented, but that as Phill is trying to draft and put forth a motion that will pass, maybe he should consider using the word “should” rather than “shall.” Phill said that it may not need to be a “shall” depending on how CAA is adopted by the domains - whether it is by the 100s or the 1000s. Jeremy said he was apprehensive about adopting a requirement in the CA/B Forum if it were seen as an abuse by the CAs in locking in existing customers making it harder to get a certificate without a corresponding benefit. Phill said that the issue had been raised at the IETF and so they specified a mechanism for obtaining the data and stating that how you treat that information is up to you. So, if you state, “we don’t observe the records in this TLD data,” so long as it is in writing, you are complying with the IETF. Ben said that it will be interesting to see what the registries do. Phill noted that the registrar for xxx was trying to place a variety of controls on their registrants. Rick said that in discussing concerns with encountering CAA records he wasn’t sure how difficult it would be to get the customer to just go off and update their CAA record. Ryan K. said he knew about the previously expressed CA concerns, but that it also will increase the support time burden and some CAs may even start to require customers to set up a CAA record before they’ll issue a certificate to the customer and the CA could have a tool during the application process that says, “hey, you don’t have a CAA record,” so I share these concerns. Ben asked that anyone interested in endorsing Phill’s proposal coordinate with him, and Rick advised Phill that it would be good to also get at least one browser to endorse it as well, since he will need more than 50% of the browser vote, too.
- Meeting adjourned until the Next Call - Thurs. January. 24th