2013-01-24 Minutes
Notes of meeting
CAB Forum
24 January 2013
Version 1
Present: Ben Wilson, Atsushi Inaba, Mads Henriksveen, Sissel Hoel, Eddy Nigg, Rich Smith, Ryan Koski, Ryan Sleevi, Gerv Markham, Simon Labram, Kirk Hall, Jeremy Rowley, Wayne Thayer, Rick Andrews, Brad Hill, Stephen Davidson, Robin Alden, Mert Ozarar, Phill Hallam-Baker
Agenda Review: the agenda was reviewed.
Approve Minutes of 10 January 2013: The minutes of 10 January 2013 were approved subject to factual corrections made by Turktrust.
News Items: NIST request for papers and 2-day event April 10-11; ICANN request to discuss Non-FQDN certificates during next F2F; and Update of Scanning results for End Entity Certificates Where CA=True.
NIST: Ben announced that NIST had released a request for papers in advance of a 2-day event to discuss security of the Web PKI April 10-11. He plans on attending and asked who else had plans. Kirk said TrendMicro would send someone. Rick said he would attend. We will discuss this further as an agenda item during the Face-to-Face meeting.
ICANN: Jeff Moss of ICANN has requested some time Tuesday morning of the face-to-face to go over potential issues that may arise with the new gTLDs if valid, pre-existing certificates are issued to entities that are not registrants under the new gTLD program. Ben said that in the past we have discussed internal domains such as .corp and .local and we have tried to alert ICANN to this issue and now they would like to discuss it. Brad said that Jeff Moss is concerned about the same things that PayPal and Google have been concerned about for the past two years-that we need to accelerate the retirement schedule for internal names that are going to be registered as gTLDs and will be globally resolvable. Brad said that the CABF should look at his previously proposed language and take action or respond that it is not going to take any action. Ben said that we need to be politically astute and aware of the issues and a dialog will be helpful so that we can take action based on a solid understanding of the situation. It would be easy to just point fingers, but we should identify the most urgent actions that need to be taken, like for instance, avoiding problems with legacy certificates by not issuing them in the first place. Brad said that we are not just talking about dot-less domains, but certificates issued to .delta, .foobar, etc. Applicants are spending up to five million dollars and are unaware that there may be valid internal certificates issued for their requested gTLDs. They will not be too happy if CAs do not revoke those certificates on an accelerated schedule, and saying that they cannot be revoked without coordinating with existing customers will not be a very good excuse when these issues have been previously raised. Brad said that over a year ago he had proposed language that he thought worked. In response to the ensuing discussion, Ben said that we did not have time to debate the language of a ballot on this phone call. Instead, we should work to understand the problem better, for instance, by scanning our certificate databases for names that are potential / applied-for gTLDs. Kirk said that we need a statement of the problem so that we know what we’re trying to fix. Ben said he’d like to see something in writing, and if so, it would be something like, “the CAB Forum already has a retirement schedule set for internal name certificates. We need to revisit it and revise it by looking at the issues to identify what more we can do to facilitate the implementation of these new gTLDs by not issuing these names in certificates or by changing the retirement schedule for these names. We can control what we do, but we cannot control what others will do, and that is another problem, etc.” Rick and Jeremy said they would be happy to continue working on the proposed ballot language. Jeremy said that when he talked to Jeff Moss, he said that ICANN is also concerned about certificates issued to *.newgTLD, and so the ballot will need to address that concern as well. Rich said that Comodo would support that approach, too, but that he is concerned about the lack of information from ICANN on what is being done on their side, so when we have our conversation with them, we will need to find out which new gTLDs are really being considered for the earliest approvals. Kirk recommended that we have a ballot prepared to place on the table for our discussions with ICANN.
Results of Scan for Certificates with CA=True. Eddy said that Yngve had been very helpful in locating some of these problematic certificates. He said that Yngve had found 60+ certificates with CA=True and no pathlength constraints, issued by a Korean CA. Eddy sent an example to the management mailing list. He explained that the CA is trusted in Microsoft’s trust store, and that he and Yngve had communicated with Tom about the CA, and that Tom was going to contact the CA. There were some certificates that did have the pathlength=0, which would mitigate the problem somewhat. None of the other parties that Eddy contacted about searching their databases for this CA=True condition have yet responded. Yngve found additional certificates with this condition which had also expired, and some of the 60+ expire in February. Gerv said that Mozilla is not affected because the Korean CA is not in their root store. Eddy said that we should continue our research and also prohibit this type of certificate in the future because the entities receiving these certificates are not CAs.
Ben asked what the procedure should be when these things are discovered. “Should we rely on the browsers to contact these CAs or should we contact these CAs and let them know that if they do not resolve it we will contact their customers directly?” Gerv said that the Browsers cannot take on the responsibility of policing every little certificate error. Eddy said that for the Microsoft root store, it is relied upon by multiple browsers like Google and Safari, so the issue is broader than just Microsoft. Kirk said that if an issue is important enough we should contact both the CA and the browsers because they might be unaware that they were doing this. And we could ask that they take action and if they don’t take action we could make the issue more public.
Rick asked if browsers might consider taking additional action, such as blocking, even when the root is not in the trust list, because even Firefox allows you to bypass such errors and these are malformed certificates. Gerv said that 60+ certificates across the whole web is a rather smallish number for a special block. Ryan Sleevi said that trying to address these kinds of security issues is too hard given that parameters in certificates can easily be changed. Chrome performs automated checks on several things, but on some things there may not be an added security benefit by blocking it. Rick believes these kinds of issues are not going away and we can’t just ignore them. Ben noted that we haven’t done a risk-threat-benefit analysis and that it would be good to know what the degree of risk is for these kinds of issues, so in the future we might want to categorize and scale them based on their perceived risk. Gerv asked, “what is the additional risk over and above your ordinary untrusted certificate?” The group discussed what might happen if a user clicked through the warnings and/or either granted an exception to the certificate or accepted it as a CA in their root / trust store. (E.g. are users subsequently exposed to other certificates signed by that site’s private key?) Ryan Sleevi said that exceptions would still subsequently fail-based on what he knows about how Firefox and other browsers are doing exceptions. The only risk is if the user were to install that certificate as a trusted CA, and they will be told that it is a CA certificate that they are installing, but if you click through as an exception, you’re only accepting it as that server’s certificate. Gerv said, so there is still no incremental risk over and above that for an untrusted certificate, which doesn’t have CA=True in the basic constraints. Rick said that, to illustrate, he had received a request from Kathleen a few weeks ago and she wanted confirmation that CAs have looked through their databases and to not just respond that they have controls in place, so similarly, it would be better if someone were to actually go through and test this scenario and verify whether browsers do behave the same universally. CAs take a hit when they mis-issue a certificate, but there are things that browsers can do and fail to do and that causes a bad light to fall on the system and make people think that the whole system is untrustworthy. Ryan S. said that browsers continue to perform risk analysis on CA problematic practices and things that CAs do that affect the reliability of their browsers. They do add software controls, in addition to procedural controls like WebTrust and ETSI, for added security. The software controls must be perceived as effective and easy to implement, because UI changes are going to be predicated on benefits to end users, and treating it differently here than an untrusted certificate provides no additional security. While one could argue that treating it with hard-fail or some extra-special error will teach people that CA=True is unacceptable, browsers are not in the how-to-run-a-CA education business. Browsers cannot do this for internal CAs that people run, which have lots of other errors. Certainly there are automated checks that can be run, and OS X will fail in its API implementation with an internally issued end entity certificate asserting basic constraints true if it is not a self-signed certificate. Android will soon be doing the same. Rick said he would feel more comfortable if someone were to test this trust-exception scenario to confirm that they are not subsequently trusted by a browser. Ryan said that browsers should ensure that exceptions do not leak beyond the site that the exception bypasses or is made for, but the general risk is no greater than the situation of an untrusted certificate, and regardless, it is a serious concern if a publicly trusted CA has violated the terms of a browser’s root store program.
- Ballot Issues
OCSP AIA requirement (Remaining BR Issue 7) - Ben said that he sent an email out on Wednesday and wanted to confirm that everyone had received it. Anyone interested in AIAs or OCSP Stapling should respond.
BR Issue 15 (IDNs and new gTLDs) - Jeremy has a draft that he, Rick and Robin are going to review for gTLDs. Brad, Rick, and Geoff still need to work on the IDN ballot. The open source code that Brad made available still needs to be tested by someone. Rick said that he would have Symantec look at the code and see how it can be incorporated into their systems. Brad said the code is being incorporated into an open source library and that the previously presented ballot language is there for someone to pick up and put into an independent ballot.
Ballot 89 – EV Processing – Rick said that he condensed the issues into five groups and that he is sending emails out regularly to get responses on the meta-issues and that the arguments and counter-arguments are all documented on the wiki at Adopt Guidelines for the Processing of EV SSL Certificates v.2 He has sent out emails on 3 issues and has 2 more to go. Ben said that we need to move these issues forward. Rick said that these discussions are all on the public list and he’d appreciate it if everyone would take a look at them and provide feedback. He hopes to present a status report on all of these issues during the face-to-face meeting where we can debate any open issues and bring them to closure.
CAA (RFC 6844) – Phill updated everyone that CAA has been approved for publication as RFC 6844. He would like the Baseline Requirements to require CAs to disclose whether they are going to do CAA records and identify which of the validation mechanisms listed that they will implement with CAA, but that at this stage of implementation it would be too difficult to make it mandatory, if that is where we are as a group today. If we are to have a ballot ready to discuss at the face-to-face, Phill asked where to place that provision in the Baseline Requirements? Ben recommended that Rich might be of some help. Phill said he wants domain holders and certificate holders to be aware that this is a facility that they can use, and he asked whether everyone agreed with this stance. Kirk said he would have to read the RFC before he would be in a position to make any comment. Phill said that he would track down the publication status of RFC 6844 (published now at https://www.ietf.org/rfc/rfc6844.txt).
Ben also asked Phill about the must-staple OID, and Phill said that he did raise the issue with the four main people at IETF and they had not taken any action, although they had been adamant that it be in the PKIX space because if people wanted to look at it and what it does, then it makes sense for it to be in PKIX.
6-7. Working Groups
Audit – Kirk provided an update on the Audit Working Group. Under the current proposal, the criteria would be frozen at a certain date every year and auditors would have to adopt changes to their audit standards within 6 months. Then there would be an effective date that would be recommended to all browsers (likely the date 6 months after the freeze date). We cannot force browsers to do it, but if just one browser does it effectively becomes enforceable for all of the browsers. Audits would be split where part of the CA audit is under the old standard and part of the CA audit is under the new standard. Don supported this approach. If six months were to be the deadline for the adoption of new audit criteria, then that would be the date that we recommend that browsers to require. We will still need to talk to ETSI about this, possibly during the face-to-face meeting at Mozilla.
Ben would like to move toward a model with chairs of working groups. Even though we generally all work on all of these things as one whole committee, it would be good to have at least one committee chair, but two, three, or even four committee / working group chairs would be fine. People could be on any working group, etc. Kirk suggested that Ben send a request for volunteers and if there are not enough volunteers for a particular group we could start filling the group list with names of people thought to be a good fit for a particular group, and then we would ask for their participation.
- Face-to-Face Planning
Ben said that he would post the proposed Face-to-Face agenda to a Google folder because it is easier to edit spreadsheets there than tables in the wiki. Rick asked whether we would have another meeting before the face-to-face. Ben said that we did not have one planned, but that he would send out an announcement for a F2F planning meeting to take place at this time next Thursday, January 31st for those who are interested and can and want to participate.
- Any Other Business
Mert stated that he would submit revisions for the minutes of the last meeting. Turktrust would like 1.5 hours of time during the Face-to-Face meeting to present findings and quantitative results and because KPMG Netherlands would be auditing Turktrust on its new change and incident management controls, which have already been implemented, and he expects that he and his associate will be able to present those recent audit results to the group. He suggested that Wednesday afternoon would be the best time for that presentation.
- Meeting adjourned until the Next Call - Thurs. January. 31st for Face-to-face Planning only. Next telephone call following face-to-face will probably be Thursday, 21st of February.