2013-05-30 Minutes
Notes of meeting
CAB Forum
30 May 2013
- Present: Jeremy Rowley, Dean Coclin, Stephen Davidson, Ben Wilson, Kirk Hall, Geoff Keating, Ryan Koski, Mert Ozarar, Tom Albertson, Joe Kaluzny, Robin Alden, Ryan Sleevi, Connie Enke, Atsushi Inaba, Gerv Markham, Eddy Nigg, Wayne Thayer, Brad Hill, Phill Hallam Baker
ICANN Presenters: Francisco Arias, Tomofumi Okubo, Jeff Moss, and Steve Sheng
Agenda review: Approved as published.
ICANN gTLD Discussion: Ben said that everyone should have received the PDF version of the presentation and turned the time over to Francisco who reviewed ICANN’s request for information to the CAB Forum. Francisco said that they would like to have their report completed by June 21.
There are two main questions that ICANN is trying to address concerning the internal name issue:
(1) How widespread is the use of internal name certificates that either do or could contain names that collide with new gTLD applications?
(2) What are the risks associated with delegating new gTLDs with names that could appear in internal name certificates issued to someone not related to the new gTLD?
ICANN would like assistance from members of the CA/Browser Forum in gathering information that will help answer these questions. Concerning the Request For Information (RFI), ICANN is willing to sign an NDA with each CAB Forum member to share information with them. The questions presented by the RFI are:
Are non-public domain names used in common names or subjectAlternativeNames?
What types of certificates are allowed with non-public domain names? (e.g., TLS/SSL, S/MIME, VPN, code signing, access control)
What anonymous statistical data can be provided to ascertain how many certificates with nonpublic domain names have been issued and how many are still valid in the following categories: i. certificate type ii. certificate lifetimes iii. country-of-origin and iv. organization
Do you allow issuing CAs under your root CA?
Are issuing CAs allowed to issue certs with non-public domain names?
Are policies being revised to restrict issuing certs with non-public domain names?
What issues are of concern from a CA operator’s perspective with regard to introduction of new gTLDs at the root of the public DNS?
Who from your CA will communicate with ICANN in discussing these issues from your perspective and that of your customers?
What recommendations can be offered for how to introduce new TLDs at the public DNS root?
How can further coordination between ICANN and root CA operators occur?
Any questions can be directed to Francisco at ICANN.
Jeff Moss said that when ICANN makes decisions or takes action it needs to be based on data. Dean asked whether ICANN had received a copy of Symantec’s presentation on internal server names because it had good comments from enterprises and explained why internal names are being used. Jeff said they had.
With regard to the first item, Ben said he did not think many internal names were in common names, but Wayne disagreed, and Ryan Sleevi said that it is perfectly acceptable for them to appear in either or both the SAN and common name, and if these were certificates for internal devices, this would commonly be the internal name, and there are technical reasons to place the internal name in the common name field, especially for older devices, some of which cannot process SANs.
Ben said that for the four or five categories of information that ICANN was looking for, most could be aggregated by the CA before providing it to ICANN. However, if that’s done without some coordination on the data, it might make it more difficult to create an aggregate analysis because each CA would respond differently. He asked Francisco to clarify the kind of data we are talking about here. Francisco said that the more information received the better. He understands there are sensitivities, and if that is the case, and the CA believes it cannot provide access to raw data, then ICANN would understand, but they are hoping for access to raw data.
Ben said that unless the data is all coming in the same way, then it’s less scientific, i.e., would need to be pulled into the right data fields. Francisco said that ICANN does not want to create a whole lot of work for CAs–they just want the aggregate data. ICANN will provide a format of how it would like to get the data. Generally, if you take a certificate and parse it, you’ll get issuance date, expiration date, common name, SANs, and for most certificates you’ll have a country code. It might be difficult for some CAs to separate out certificates in the public name space vs. certificates issued for non-public name space. Francisco said if CAs could provide access to the internal names of certificates, that would contain most of the information ICANN is looking for. For the data, ICANN is looking for all non-public names not just the ones that have been issued under applied-for gTLDs. They are looking for all because there will be future rounds of gTLD delegations. Jeremy said he didn’t think that ICANN wanted to know which certificates contained .local or .example, because those are reserved and ICANN shouldn’t really need to know that information.
If the ICANN deadline is June 21, then working back that is three weeks away. ICANN would like the data within the next week or two. Because the CAB Forum in-person meeting is coming up, CAs will need at least until the 21st of June. Wayne said that GoDaddy had already pulled most of the data needed. Robin said Comodo should be able to provide a response in about 2 weeks. Kirk said that TrendMicro had never issued any of the certificates, so they don’t have an issue with this. Stephen Davidson said that they would have to look at their information and get back. Eddy said that StartCom has never issued these kinds of certificates, so they are not affected. Ben said that everyone should set a goal of getting it taken care of or arranged so they know what they’re doing before they leave for the face-to-face meeting. He suggested that all members review the request and get back to ICANN with a response. He then mentioned that ICANN has requested observer / interested party status.
Francisco asked that all CAs contact him and email him with any questions.
Approve Minutes of 16 May 2013: Approved without objection.
Ballots: We have received comments about withdrawing Ballot 100 for further editing. Mozilla had commented. Gerv said that pulling the ballot had support from Mozilla, Google and Opera. Brian Smith had set out their position quite well. He has some good ideas, and as Brian had said, if we extend the deadline, we’ll be back here next year. Joe said he agreed that we cannot keep extending, but he thinks that the date chosen initially was too early. When he brought it up a year ago, he expressed these concerns and it was said that we will re-evaluate things next year and see where we are at. He knows they won’t be ready by August. In most cases he would agree that extending deadlines is not a good idea. Now it seems like he is looking at a date that was too short in the first place. Now it seems like some members have a pretty hard stance on it without admitting the possibility that we screwed this up. Gerv said he doesn’t remember who talked about reevaluating it, but proponents of the ballot ought to look into that. Stephen said the issue was raised that it is dependent upon third party vendors. Those CAs who are dependent on third party vendors are stuck. As we’ve worked on guidelines in the past we’ve left wiggle room where there would be potential problems.
It was asked whether anybody besides Wells Fargo would have trouble. Stephen said Quo Vadis is going to be pushed to comply by the deadline. Proponents of the ballot said they support a proposal to exempt sub CAs that are constrained, and that helps on Microsoft on the OCSP side. There was discussion about Mozilla audit requirements and technical constraints and Tom asked about whether this had to do with exempting subCAs from audit requirements. Ben said he thought where Tom was going was that Wells Fargo doesn’t issue a whole lot of SSL certificates. Phill said that doesn’t matter (the Microsoft CA that got busted in the Flame attack was so small that it didn’t get noticed) – even just one CA that isn’t able to provide strong certificate status capabilities is a problem. Ben agreed and noted that if Opera, Google, and Mozilla are not in favor of the ballot, then even if Microsoft and Apple voted yes, and assuming that all browsers vote, then it likely won’t pass.
Ballots 101 and 102 are not that controversial, and voting starts Friday.
Ballot 103 doesn’t seem controversial. Ben will accept comments from Rob to change subsection 5 from “must” to “should”. Ben said if he could get Comodo and Mozilla to endorse it he can move forward with it.
News and announcements: NIST comment deadline is next week. Dean said that recent posts from Netcraft have shed a negative light on the industry, and it is incumbent for all of us to improve the reputation of both CAs and browsers.
Agenda planning for Munich: Ben noted that Tuesday morning we’ll talk about industry / browser developments and about Webtrust, ETSI, and better collaboration on audit frameworks. Tuesday afternoon we’ll talk about the NIST CP document and improving CA security frameworks and then any issues on the issues lists of the CABF guidelines. We’ll wrap up Tuesday afternoon going over improvements to the CA/B Forum website. Tuesday’s dinner, in fact the meeting site, is hosted by Symantec. Tuesday we’ll wrap up by 4PM because there is something planned. Dinner Wednesday night is on our own, but Symantec has a place picked out for us. Wednesday morning we’ve left a slot open to discuss things that came up during Tuesday’s discussions that we can pick back up. As for logistics, there are several slots still to fill in, whether it is for 15 minutes, 20 minutes, 30 minutes or even 60 minutes. The rest of the discussion before lunch on Wednesday will cover improvements to revocation/certificate status, subCA technical constraints, and a review of governance issues like the bylaws and IPR policy. After lunch we’ll discuss the Netcraft article on revocation and browser behaviors related to the work of the WPKOPS group. After a break we’ll discuss reinvigorating EV SSL and then wrap up by 4PM again. Thursday morning we’ll review the status of Certificate Transparency, OCSP Stapling and other technological solutions for providing better certificate status. After a break we’ll spend two hours reviewing the Baseline Requirements for Code Signing Certificates.
Any Other Business: None.
Next teleconference: Next call will be two weeks after our face-to-face meeting (June 27th).