<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=iso-8859-1"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin-top:0in;
margin-right:0in;
margin-bottom:10.0pt;
margin-left:0in;
line-height:115%;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal style='margin-bottom:0in;margin-bottom:.0001pt;line-height:normal'>All,<o:p></o:p></p><p class=MsoNormal style='margin-bottom:0in;margin-bottom:.0001pt;line-height:normal'>Here are the approved minutes of our call in December.<o:p></o:p></p><p class=MsoNormal style='margin-bottom:0in;margin-bottom:.0001pt;line-height:normal'>Ben<o:p></o:p></p><p class=MsoNormal style='margin-bottom:0in;margin-bottom:.0001pt;line-height:normal'><o:p> </o:p></p><p class=MsoNormal style='margin-bottom:0in;margin-bottom:.0001pt;line-height:normal'>[cabfman] Notes of meeting, CAB Forum, 6 December 2012, Version 1<o:p></o:p></p><p class=MsoNormal style='margin-bottom:0in;margin-bottom:.0001pt;line-height:normal'>Notes of meeting<o:p></o:p></p><p class=MsoNormal style='margin-bottom:0in;margin-bottom:.0001pt;line-height:normal'>CAB Forum <o:p></o:p></p><p class=MsoNormal style='margin-bottom:0in;margin-bottom:.0001pt;line-height:normal'>6 December 2012<o:p></o:p></p><p class=MsoNormal style='margin-bottom:0in;margin-bottom:.0001pt;line-height:normal'>Version 1<o:p></o:p></p><p class=MsoNormal style='margin-bottom:0in;margin-bottom:.0001pt;line-height:normal'><o:p> </o:p></p><p class=MsoNormal>1. Present: Rick Andrews, Ben Wilson, Kirk Hall, Yngve Pettersen, Atsushi Inaba, Eddy Nigg, Jeremy Rowley, Dean Coclin, Mads Henriksveen, Sissel Hoel, Wayne Thayer, Ryan Koski, Ryan Sleevi, Geoff Keating, Gerv Markham, Rich Smith, and Håvard Molland.<o:p></o:p></p><p class=MsoNormal>2. Agenda Review: the agenda was reviewed.<o:p></o:p></p><p class=MsoNormal>3. Approve Minutes of 19 Nov 2012: The minutes of 19 November 2012 were approved as published. <o:p></o:p></p><p class=MsoNormal>4. Report on ETSI CA Day: Among those in attendance were Yngve, Ben, Robin, Mads, Sissel, Iñigo, Dean, Tom, Arno, Nick Pope, Steve R., Tony Nagel, Moudrick, and several others. During CA Day, Dean, Ben and Robin provided an update on the implementation of the Baseline Requirements. One of the main topics during CA Day was CA auditing, and Nick Pope, Iñigo, Arno, and Christoph Sutter updated attendees on CA auditing and the work of ETSI STFs. (See Arno’s email dated 18-Dec-2012.) Representatives of the European Commission explained the proposed update of regulations concerning the 1999 Electronic Signature Directive (1999/93/EC). The main purpose of the regulations is to remove legal barriers to cross-border transactions (see <a href="http://docbox.etsi.org/Workshop/2012/201211_TSP/1_TSP%20-%20Berlin%20%20-%20eID%20&%20Trust%20Services%20Regulation%20-%20Galler%20-%2029.11.2012.pdf">http://docbox.etsi.org/Workshop/2012/201211_TSP/1_TSP%20-%20Berlin%20%20-%20eID%20&%20Trust%20Services%20Regulation%20-%20Galler%20-%2029.11.2012.pdf</a>), but it might also include an initiative to regulate SSL certificates. The approach would be to recognize EV certificates as “qualified website authentication certificates” IF the issuer is subject to member state supervision. Ben said he had reviewed the draft regulation (<a href="http://ec.europa.eu/information_society/policy/esignature/eu_legislation/regulation/index_en.htm">http://ec.europa.eu/information_society/policy/esignature/eu_legislation/regulation/index_en.htm</a>) and that it did not go into those specific details. Ben also reported that several CAs in the meeting questioned the efficacy of that solution because there would not be any further browser enhancement of trust displays for such certificates. He also said that he had suggested that EV could be used as a standalone solution and that the EC should tailor a separate solution around the perceived problem, whatever it is that they are trying to solve, e.g. Diginotar, etc. <o:p></o:p></p><p class=MsoNormal>Kirk asked whether any additional details were available. Dean said that from his conversations, he understood that no one would be required to issue them and no one would be required to use them, so there would be no demand pulling them with “we have to have this type of certificate.” He said that maybe there might be some issuers in the EU who in the future will try to do marketing around this type of EU-qualified SSL certificate on the basis that they are more secure because the CA is also supervised by an EU member. Dean also noted that enhanced browser displays had been mentioned during the meeting and he said he didn’t think it would work because of the difficulty in getting browsers to change the UI. Yngve noted that he also mentioned that it would be too difficult. <o:p></o:p></p><p class=MsoNormal>Ben said that there were also discussions about improving the acceptability of audits of Trust Service Providers across the EU, but that would be the topic for a whole other discussion if any members want to form a group around that topic. For instance, we could schedule a telephone discussion with Nick Pope and other representatives of ETSI. He also said that when we have our meeting in Munich, Nick has asked that we schedule an opportunity to delve into EU/ETSI issues, maybe on a separate day if facilities are available. Kirk requested that the discussions of EU/ETSI issues in Munich be well-planned so that they are productive for all CAB Forum members and not a lengthy update on the status of the work. Instead, the dialog with ETSI and CAs located in the EU should include sufficient explanation of: why a particular issue is important for us, what direction we are heading and why, whether identified goals are worthwhile, and what we as CAs must do with the information as actionable tasks toward accomplishing those goals. <o:p></o:p></p><p class=MsoNormal>5. Review of Ballot Status and BR Issues List<o:p></o:p></p><p class=MsoNormal>Ben asked for comments on a proposed resolution of BR Issue 7. He paraphrased the current proposal to resolve BR Issue 7 (revocation of Intermediate / Subordinate CAs) was that certificates issued after 1 August 2013 that are not issued directly by the root must have a pointer to the issuing CA’s certificate in the AIA. Kirk asked for an explanation of why this was needed. Ben referred to the email of 5 December 2012 - “Improve the user experience by helping clients verify certificates for misconfigured servers (as he has mentioned earlier, 1 server in 50 does not send a full chain, 1 in 1000 does not send a full chain and automatic completion is not possible, …”. Kirk said he needed further explanation of what is meant by “server misconfiguration”, and Ben explained that many server administrators do not properly install intermediate certificates. Kirk asked whether a better resolution would be just to require customers to install all required intermediate certificates. Gerv noted that because Firefox does not download any intermediate certificates, any server that is misconfigured in this way won’t work in Firefox, and therefore, there are not many servers that are misconfigured in this way.<o:p></o:p></p><p class=MsoNormal>Yngve said that his information indicates that about 1 in 50 (2%) of servers do not deliver a complete certificate chain. Eddy said his information indicates that the number is higher. Yngve said that Ivan Ristic’s figures say it is 7%. Wayne noted that many users may be more inclined to blame the CA and not figure out that it is a missing intermediate. Yngve says that they actually blame the browser. Ryan Sleevi asked why the solution has to be a “MUST” even though he is well-aware of the problem with misconfigured servers, including servers that deliver their chains in reverse order in violation of the TLS specification. He supports a “SHOULD” solution that allows CAs to address customer needs instead of a “MUST” when the problem at its core is a customer configuration issue. Rick said the benefit might be lower support costs, but that it may not be a benefit if browsers do not commit to using the AIA to build the missing parts of a chain. Yngve noted that Opera and Windows use the AIA. Wayne asked if there was a reason why Firefox does not use the AIA. Ryan S. interjected that AIA chasing isn’t the best solution because of the performance implications and that support costs are incurred only by the CA that issues the certificate. Gerv noted that Mozilla does receive support inquiries about this problem, but that he doesn’t believe there are that many. In answer to Wayne’s question, Gerv said that he suspects that Mozilla has not implemented it because it is not a priority and because as Ryan noted, there are performance implications, and if the misconfiguration is concealed by browser behavior it will just increase the problem of poor performance. Yngve said the performance problem depends on how you implement AIA chasing. Opera caches the certificate into the repository, so for a single issuing CA identified by the AIA URL, Opera does one request and then never again. Ryan said that he was aware of caching, but if browsers handle the problem it encourages misconfiguration. He would also like the “MUSTs” in certificates be kept to a minimum so that certificates can stay small, like the omission of the OCSP URI for OCSP stapling. Ben asked Ryan why he opposed it if it was a CA requirement and not a browser requirement. Ryan responded that he didn’t see this issue rising to the level of a universal problem that needed interference between all CAs and their customers. Ben said that in order to bring this issue to closure we need to figure out whether to move forward to a ballot, but that it didn’t sound like there would be more than the required 50% of browser support, so that if we didn’t take action on it currently, we should at least document some of the reasons why didn’t act. Ben asked Geoff what he thought, and he said he agreed with Ryan—that “SHOULD” would be better than “MUST”. Yngve asked about removing OCSP when there is an agreement for stapling. Ryan said that we need to see where we’re going with “must staple” and that when we have an OID for it, it makes sense to include the AIA even if a stapled response is received, if the client needs to go and fetch a fresh response, then at least they can go do so. Yngve said that he could remove the “MUST” for the Issuer URL in the AIA but leave the OCSP URL. Ben asked whether Mozilla and Google would still support cleaning up the problematic language that might still exist in the appendix concerning the OCSP URL and OCSP stapling. Ryan explained that the current wording allows omission of the OCSP URL if there is going to be stapling, but there is no way presently to enforce that. Yngve noted that most servers will need the OCSP URL information in the certificate in order to configure their own retrieval of the OCSP information for stapling and leaving it out of the certificate will lead to configuration errors. <o:p></o:p></p><p class=MsoNormal>6. Ballot 89 Issues<o:p></o:p></p><p class=MsoNormal>Rick explained that he had created a list of 21 issues raised and has put them on the wiki - (see <a href="https://www.cabforum.org/wiki/89%20-%20Adopt%20Guidelines%20for%20the%20Processing%20of%20EV%20SSL%20Certificates%20v.2">https://www.cabforum.org/wiki/89%20-%20Adopt%20Guidelines%20for%20the%20Processing%20of%20EV%20SSL%20Certificates%20v.2</a>). He inquired about the procedure that should be used to resolve these 21 issues. Rick wants to avoid separate discussion threads for each issue. Objections came mainly from Opera, Apple, Google and Mozilla. Many of the comments have asked for additional coverage of certain topics, but Rick would like to avoid that unless there is widespread agreement. The issue he is facing is that the comments on any given topic will come from one person, but no one else chimes in to say that they also support the comment. Rick would like to use a better way of getting consensus. Ben said that the Survey Monkey account could be used. Kirk suggested that Rick start with what appears to be the toughest or most fundamental issue and re-frame it in a simple way that presents the potential views and then gather input and then try to reach his own conclusion on the sentiment of the group and then move to the next issue and so on until all of the issues have been discussed and then put the entire work out for a ballot. Or Rick could put several issues out for discussion in batches and then make his own conclusions based on the discussions. Rick said that it was a good idea provided that everyone else will participate. Ben said that if we do decide to use some form of online survey tool he would be willing to help bug people until they’ve responded. Rick said that he had received great feedback from Mozilla, Apple, Opera, and Google, but that they’ve all commented on different things. Gerv said that he does prefer a single email on a particular issue rather than a list of 21 proposed additions or modifications of text because big requests just get pushed to the bottom of the pile. Ben said that whatever we do, we’ll aim at minimizing the time needed to respond. <o:p></o:p></p><p class=MsoNormal>7. WebTrust and ETSI Implementation of Baseline Requirements Audit Criteria<o:p></o:p></p><p class=MsoNormal>Kirk said he would like to move things to completion and get them off our agenda. Just to recap, he noted that he had circulated a proposal to ballot it without imposing it as a requirement by CAs on other CAs, but only browsers can through their root programs, so his ballot suggested that it be a recommendation of the Forum to browsers that the WebTrust and ETSI requirements apply to all CAs after a certain date, for example, January 1, 2013. Tom responded to the email saying that the motion wouldn’t accomplish anything, so Kirk is recommending that we now declare this issue finished and move on. Therefore, it is now up to the browsers to announce through their root programs exactly when they are going to impose Baseline Audits on their participating roots. Dean said that he had talked to Tom last week about the audit requirements and he had indicated that he would not have a problem with a January 1<sup>st</sup> date, so he was hoping Microsoft would make that announcement. Gerv said that he would be talking with Kathleen and that he would check to see about the January 1<sup>st</sup> date as well. Kirk suggested that we look up the ETSI reference for the Baseline Requirements audit and communicate that to the browsers so that they have the right language for their root programs. Ben suggested that we circulate a draft notification email to the browsers using the management email list simply as a way of getting motion forward to closure on this issue, or we could do it directly on the side as a subcommittee. Kirk said he considers it done without further action. Ben said that we will then record here in these minutes that we are done and that there is no further action needed by the CAB Forum and that we are expecting the Browsers to begin implementing WebTrust for Certification Authorities – SSL Baseline Requirements Audit Criteria v.1.0 and ETSI TS 102 042 V2.3.1 in accordance with Guidance for Auditors and CSPs on ETSI TS 102 042 for Issuing Publicly-Trusted TLS/SSL Certificates (ETSI TR 103 123 V1.1.1). Kirk said that Ben could also send out an email to browser members in this regard. <o:p></o:p></p><p class=MsoNormal>Kirk also recalled that in an earlier email he had suggested that we move toward a formalized process for incorporating audit standards in our work and that he had suggested July 1st of each year. All changes that happened in the prior 12 months would be fixed as of that date and we would tell the auditors that we would like their audit criteria updated as of January 1<sup>st</sup>. It could either be effective on CA operations as of January 1<sup>st</sup> or it could be for audit periods that begin on or after January 1<sup>st</sup>. With that approach there wouldn’t be fewer conflicts with audit requirements. If members like this suggestion, Kirk will propose it as a ballot. Ben said that the suggestion is fine in terms of simplifying the process as long as we don’t simplify it so much that it prevents us from fine-tuning the effective dates for certain things. Kirk said that it would be fine to make a provision effective immediately and that until it is in an audit standard it would be considered a voluntary best practice that members should implement because it is clear from our conversations with the auditors and browsers thus far that it will not be enforceable until it is incorporated into the audit criteria. Gerv suggested that we check with auditors to make sure that a six-month cycle is an acceptable timeframe for changes to be incorporated because it might not be workable. Ben agreed and said that we can only control what we do, and that therefore the key thing will be to limit ourselves to this cyclical, July 1<sup>st</sup> framework. Gerv said that alternatively we allow them to tell us when they have a stop-start in their work cycle and then we deliver to them a version where the errata to a certain date have all been incorporated, and then they go off and they’re done when they’re done. Ben said there is a benefit if we can synchronize updates between the two audit frameworks. Jeremy said he liked Gerv’s approach because we really can’t control what the auditors or browsers do in terms of timing audit updates, but we can set effective dates for ourselves, so he would like to continue working as we’ve been doing up until now. Kirk said that the benefit of his proposal is that it provides more structure and a less chaotic environment, especially for CA compliance and audit-preparation purposes. Kirk said he’d talk to the auditors about their document update cycles. Ben suggested that we put this on the agenda for the next face-to-face meeting. Kirk said he’d like to have something concrete prepared as a ballot so that we don’t have endless discussion. <o:p></o:p></p><p class=MsoNormal>8. IPR issues<o:p></o:p></p><p class=MsoNormal>Ben said that he contacted Entrust and they had indicated that they would participate again if we adopted the draft version of the IPR Policy that he had circulated, which included participation defined as voting in favor of a ballot or as contributing. Kirk asked about RIM and Identrust because he didn’t think we should rely on the response of just one company. Dean said that RIM has not participated in the working group but his understanding was that Identrust was amenable to the same position as Entrust. Kirk said that TrendMicro strongly disagreed with it being workable and that they opposed the changes because Entrust would be under no obligation to disclose their IP. Gerv said what if during the process of developing a standard that we discover that the essential claims of several members are included and yet everyone is in favor of the standard and we get to the vote and suddenly one of the members who has been quiet and hasn’t made a contribution suddenly votes no and then later reveals that they held IPR after it has been adopted? Ben said that he thought that scenario could be easily resolved by cancelling the vote or otherwise legally addressing the bad faith of a participant who engages in that kind of behavior. Gerv said that this would allow disruption of the work of the Forum because we would have to go back and change the standard. Ben said that he intended to push forward with a ballot on this version of the IPR and find two members willing to endorse the ballot even if TrendMicro and Mozilla intended to vote against it. Gerv asked if that Ben did intend to move forward that he include a requirement for tracking who are the contributors during the document’s lifetime because that will reduce the number of disputes in the future because it will contemporaneously record it when it happens and give participants much greater certainty about who have and haven’t licensed their patents. Ben said he would make it part of the ballot. <o:p></o:p></p><p class=MsoNormal>9. Governance Reform Issues<o:p></o:p></p><p class=MsoNormal>Ben said he would create an official version of the Bylaws based on Ballot 94 for posting on the wiki and the web site. He said that he added this item to the agenda in order to keep moving forward on issues of transparency and for continued discussion of how we allow SMEs and other interested non-members to participate. Kirk said that we have a framework in place. Jeremy said he thought that Kirk was going to work on some amendments. Ben noted that with the holidays coming up that he figured everyone would like to take a break. Kirk said that he had some minor improvements that he would like to make, including posting of ballots in track-changes mode to make it easier to see what is involved, and that the format should include a description of the problem being addressed, etc., but we can give the bylaws a try for a while and see how they work. Ben said that we ought to revisit the bylaws every once in a while because we want to be proactive. Rich said that our ballots used to focus on a single set of issues and the ballots have gotten away from the format where the single issues were easier to track, so we may not need a ballot to require that, but we should give some thought to encouraging people to go back to how we used to do things where the ballots were smaller and clearer. Ben said he agreed, but that part of the problem may have been we have been trying to accomplish so much over the past year and a half. Ben said it would be nice if someone would volunteer to help with ballots by reviewing them, reformatting them for consistency, etc., and that maybe we can experiment with some templates without being bound—sort of like when they build a campus without sidewalks and then lay the cement after they have figured out the traffic patterns. Rich said that it may have arisen out of the fact that groups of BR issues were assigned to certain individuals and that they would try to address multiple issues with a single ballot, but we shouldn’t do that going forward.<o:p></o:p></p><p class=MsoNormal>10. Development of new content for web site<o:p></o:p></p><p class=MsoNormal>Kirk said it would be helpful to outline what we want for each section. Ben said that he would work on giving everyone a section of the web site to work on along with a brief explanation or bullets of what the content would include. Rich said that Ben should circulate the proposal to the list and maybe that will bring in some volunteers.<o:p></o:p></p><p class=MsoNormal>11. Any Other Business.<o:p></o:p></p><p class=MsoNormal>Yngve announced that he would be leaving Opera the first week of January. Håvard said that Opera will need to determine whether his workload allows him to participate in Yngve’s place, but that someone would be assigned as the contact person. Ben said he would like to see Yngve participate as an invited expert. Rick and others said they would look forward to Yngve’s continued participation on the public list.<o:p></o:p></p><p class=MsoNormal>Dean reminded everyone that he had circulated a discussion FAQ of the Baseline Requirements and the BR OIDs and that he would appreciate getting everyone’s feedback on it. Goal of the FAQ would help explain the BRs to relying parties.<o:p></o:p></p><p class=MsoNormal>Ben asked about whether the CAB Forum web site should refer to Entrust and Identrust because if we want everyone to abide by the BRs, then we ought to include their information even if they are not CAB Forum members—just to make sure we’re advocating adoption. Eddy asked that it be published also as a PDF. <o:p></o:p></p><p class=MsoNormal>Kirk noted that the comments received about internal name certificates shows a big flaw in our outreach to other CAs and their customers. These groups are coming now and asking when and why did we do this, so this shouldn’t happen in the future because we need to do a better job of announcing and circulating pending proposals and getting feedback when we are proposing anything that will have a substantial impact on their business and their customers. Dean said that we need to publish Brad’s paper. Jeremy said that with the Baseline Requirements we did circulate the proposal on the Mozilla list and gave people more than 30 days to comment and after changes were made based on the comments we went through another 30-day review period. Kirk asked whether people had to find them. Ben said that we reached out through email with an approach that we thought was adequate but that in hindsight maybe it wasn’t good enough, but that it is just hard to contact people if you don’t know they are interested and the degree of effort put in to outreach is a relative measure because people around the world are speaking other languages on an everyday basis and read different sources to get their information. Yngve said that sometimes the people who are affected don’t even realize they will be affected until afterwards, so they would not have submitted any comments had they known. He suggested that the CAs need to look through their customer bases and identify those likely to be affected and then get feedback to provide the CAB Forum. Jeremy said that Symantec did do a survey. Dean said that Brad’s paper was in response to Symantec’s survey. Dean said we need to get the information on the web site. Kirk said we should have done a better job. Ben reminded Kirk that he wasn’t involved at the time so he doesn’t fully understand what we did or didn’t do. Jeremy said that several of us were opposed to it. Kirk said that if there had been more public input it may not have been adopted. Jeremy responded that there was substantial opposition to internal server names and that if we had gone out for more public comment we might have received the same proportion of input for and against. Kirk said that we should have reached out to a few online technology magazines to write about it because we should have known that it would be a big change that would affect a lot of people. Dean urged that we at least publish Brad’s paper on the web site, and Ben said that he would take that down as an action item.<o:p></o:p></p><p class=MsoNormal>10. The next call will be Thursday, January 3, 2013<o:p></o:p></p><p class=MsoNormal>Meeting adjourned.<o:p></o:p></p></div></body></html>