2013-03-07 Minutes
Notes of meeting CAB Forum 7 March 2013 Version 2
Present: Rick Andrews, Atsushi Inaba, Dean Coclin, Ryan Koski, Atilla Biler, Jeremy Rowley, Gerv Markham, Brad Hill, Ryan Sleevi, Ben Wilson, Rich Smith, Wayne Thayer, Phill Hallam-Baker, Mads Henriksveen, and Cornelia (Connie) Enke
Agenda review: The agenda was reviewed and approved.
Approve Minutes of 21 February 2013: The minutes of 21 February 2013 were approved as published.
Review of Ballots: Ben stated that Ballots 96, 97 and 98 all passed. He didn’t send out an announcement yet that Ballot 98 passed, but he will. Straw Poll for the meeting in Turkey, Ben has not tallied up the total, but he thinks that B and C are in the running and that B is the choice. He will confirm it and send out an email.
NIST Workshop panels: DigiCert joined in 3 panel submissions that were accepted. One is the work of the CAB Forum, another is on certificate transparency, and he thinks another deals with things going on with the Federal Government. On the CAB Forum Panel, Ben assumes Andrew of NIST will be in charge, and that Arno Fielder of ETSI and Jens Bender of BSI are the others on the panel. Each presentation is for 20 minutes, so it will be a rapid-fire discussion of various issues. Ryan Sleevi said that Google had its presentation on Certificate Transparency accepted and will address the technical and implementation side. Dean noted that the Draft CP is in the preliminary stage right now. It was developed in conjunction with an industry-government group of people including most of the browsers and large corporations as well as big government agencies. Everyone involved in the CP discussions so far is well aware of WebTrust, ETSI, CAB Forum, baseline requirements, the security documents, etc. The intent of the group has been to fill in gaps-that is why the CP does not address identity vetting in detail. The final version will come out on the NIST day in April where there will be a formal request for comment. Connie commented that we should have a summary of all of the requirements so that there are not such a bundle of documents. Ben suggested that we put this (coordinating requirements) on the agenda for the meeting in Munich to see how far we can get creating a summary of requirements.
Phill said that when the Department of Commerce is serious about things it usually holds two workshops. They will hold a first workshop that is from a wide range of directions and they will take written submissions. Then they will hold a second workshop that is a bit more specific. That’s what they did to try and address spam / unsolicited email. Brad thinks that the two requests are originating from two different places in the government. The CPS and related documents are originating out of the NSA, and the workshop is originating out of the Department of Commerce. Ben noted that we’re faced with a problem in this industry in that we are hit by so many different vectors. It would be nice if all of the vectors could come together so that what we’re expected to do would be more uniform.
ICANN Letter: Ben will finalize the ICANN letter and send it out today. He is not going to send it out for a final vote. Phill suggested that we post the letter on the website so people can be aware of how we feel and to raise the profile.
IETF: Phill, Jeremy, and Ryan S. are going to the IETF meetings next week in Florida. A report on the results of the IETF meetings will be put on the next agenda.
Java default configuration issue: Ben mentioned that Java’s default configuration is to not check certificate status, which is not good for code signing. You have to go into the control panel for Java and manually configure it, which nobody does. Also, if you have a trusted certificate and the code is signed, Java doesn’t give the user any warning, it just installs. So Oracle has simply adjusted the risk profile without revocation checking there is no true corresponding benefit or compensating security measure. Ben had asked the W3C app security group whether a review of this was within the scope of their charter, and Brad had replied that it was not. Java Oracle maintains its own trusted root store. Rick noted that he had met with some Oracle folks at RSA and he told them about the CAB Forum and had expressed an opinion that they should participate. Ben asked that Rick pursue them a little bit more given the light of this because Java/Oracle sounds like a good candidate to join the Forum.
Requests to join / Requests to translate guidelines: Dean and Ben have created a template form that goes through what it takes to become a member of the Forum, if anyone needs a copy, contact one of them. We have not heard back yet from the Estonian CA or the Korean CA that we have replied to. With regard to translation requests, a few members had asked Ben to follow up with the Japanese CAs to see about obtaining the most recent Japanese translations of the guidelines. We have had difficulty recently communicating with the Japan CA Forum. Dean agreed to follow up with Yoshi to see if we can get a copy of the more-recent Japanese translations of the guidelines.
1024-bit Legacy Roots-Bruce Morton issue: It was noted that there has been a lot of discussion on the list. Jeremy noted the issue was that since it’s publicly trusted it might be subject to certain requirements. That’s something they have to work out with the application software vendors. Publicly trusted is defined as a certificate that’s chained to a root embedded in a trust store.
Dean said Symantec has the same issues. His understanding is that these customers have to use these devices and that there is a particular root that is embedded in the device and that’s the only one that they will trust, and therefore they can’t go off of a private hierarchy because there are millions of these devices out there already with the embedded root and that for most there is no connection to the public internet, and therefore these certificates will not be seen in the wild.
Jeremy stated that is correct, but that doesn’t exempt them from the Baseline Requirements, if they want an exemption from the Baseline Requirements then that is something that they have to bring up with the application software vendors, not the CAB Forum. They could bring it up with the CAB Forum, in the form of a proposed amendment, and they already have the proposed amendment for the exceptions under section 12, but what they’re looking for is an exemption to the 1024-bit requirements. Opinion is split a little on whether application software vendors can say it is OK as long as the CA does not include the CA-identified Baseline Requirement OID in the certificate, versus whether the CAB Forum should do an amendment to permit those kinds of certificates.
One position is that the CAB Forum should be creating exclusions so that these are truly baseline requirements, while the other position is that the CAB Forum should not be creating exclusions because there should be baseline requirements and the more we make exceptions to these things the less it looks like baseline requirements and the more it looks like CAs are just putting in all of their practices that they want to as they come up with them. Another argument is that allowing certain exceptions may cause favoritism towards some CAs over others just because they are older.
Ben wondered whether application software vendors should be polled on the issue, for example, having the CAB Forum recognize that certain legacy roots were embedded in applications before the baseline requirements, and grandfathering the root that was embedded before X day by Y application vendor, based on the application vendor’s say. He also said he thinks that this issue will resolve itself over time.
Dean said that time is of the essence. There are immediate issues for new certificates that are issued off of a new hierarchy that would fall under the BRs and be subject to the new rules, but obviously the devices in question can’t handle either the key size or other roots and so there’s no choice in this matter. He’s curious about what browsers and third parties have to say on the issue. Ryan S. said that Jeremy captured his position pretty well. Either we’re putting exceptions in the BR that lets a vendor be BR compliant, and then it falls upon the root stores to set their requirements which are BR plus x, y, or z. Or we incorporate x, y, and z in the BR and the application vendors have to say you’re not compliant with x, we understand that, and we’ll make an exception. There have already been browsers that are already granting those exemptions from the BRs. Both Microsoft and Mozilla have put forward certain parts of the BRs that they’re willing to overlook for a period of time while working through compliance issues.
Application software vendors may be able to address these issues with blacklisting a particular hierarchy as an alternative to putting exemptions in the BRs. “For example, while it’s a publicly trusted root, it’s no longer a concern for any of our application products because anything issued beneath this particular chain–which supposedly should never be seen on the internet–will never validate with our product.” The reality is that the application vendor would need to understand the risk profile presented to the application’s users. The situations and risks are going to vary depending on what exemption is being requested, and that may depend on working with the CA in understanding the relationships that browsers have with their users and the openness of their root programs. For example, Mozilla is very transparent with their root program and very community involved.
The CA Browser Forum would really like to hear from all browsers on this issue. From the relying party perspective, Brad said he didn’t have strong opinions one way or the other, but that he doesn’t think that there should be devices 10 years from now that only have 1024-bit keys and that maybe this is a good forcing function.
39-month issue for information about existing customers raised by Don Sheehy: Gerv talked with Kathleen. They don’t have a strong opinion, in that this isn’t data they primarily present in the primary UI to the user, he doesn’t think they should change the BRs, and they think that the interpretation is right that you need to do it, straight up, not just a 39-month period of bringing it in, but he would also accept that as an exception on the audit. Don was not on the call. Ryan S. said he liked Gerv’s response and that the Mozilla policy reflects Google’s position on this.
Status of website rewrites: Ben said he hasn’t had any time to do editorial improvements to figure out how it should all go. He would like to start to put some of that content on the site as it is now, and restructure the site before we hand it over to anybody else that might help us improve it. As long as it doesn’t change the navigation of the site, everyone agreed that we can add those things. Ben will publicly post things either in a batch, or major things in a single email.
International Domain Names and Unicode Spoofing: Brad, Rick, and Geoff have communicated a little on the issue of the Unicode code-checking program and whether or not it was going to be delayed. Brad said that Google had already submitted another implementation to check for spoofing to ICU that he would circulate to the mailing list, which he did immediately following the call.
Code signing discussion: Dean gave an update on the Baseline Requirements for code signing project. He noted that at the face-to-face meeting in Mountain View, we had decided to start a code signing authentication working group to try to address some of the issues that have come up with code signing authentication. The goal is to come up with some kind of baseline requirement for code signing authentication. There are a lot of people who have volunteered to be on the committee. Tom Albertson volunteered two people from Microsoft, Ryan from GlobalSign, Jeremy and Ben from DigiCert, Rick and Robin from Comodo, Arno from TSystems, Kirk from TrendMicro, Connie from SwissSign, and Mert from TurkTrust. Jason Crawford from Symantec will be leading this effort. Wayne and Dean will start an email list. Ben suggested that there be a bi-weekly meeting when the CAB Forum isn’t meeting. Dean liked the idea. The charter is to look at the current Microsoft and Mozilla requirements and recent incidents to see where things went wrong and to engage in potential information sharing. There is a base draft document on the wiki for code signing that we’ll look at. The goal will be to start work on something, meet for a half-day session at the Munich meeting if possible for whoever can attend and work on a goal of coming up with a baseline document.
OTA CA Best Practices: The OTA has published a CA best practices document. It includes a pledge or self-assertion of adherence to CA best practices, mainly based on the CAB Forum’s security requirements document. Ben has a draft that he will post to the list that is pretty much final, but he would like to solicit comments from the CAB Forum on the pledge. There may be concerns about committing on paper, but the pledge will not be posted on the Internet. The OTA web site will say, “The following CAs have agreed, accepted and endorsed that these are CA best practices.” Ben will circulate the pledge for people to take a look at.
Meeting adjourned until the next call – Thursday, 21 March, 2013 (please note that your local time may have changed due to daylight savings).