<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:Wingdings;
        panose-1:5 0 0 0 0 0 0 0 0 0;}
@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:8.0pt;
        margin-left:0in;
        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;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:8.0pt;
        margin-left:.5in;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
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;}
/* List Definitions */
@list l0
        {mso-list-id:1152984788;
        mso-list-type:hybrid;
        mso-list-template-ids:-489245282 974044728 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
        {mso-level-start-at:7;
        mso-level-number-format:bullet;
        mso-level-text:-;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Calibri","sans-serif";
        mso-fareast-font-family:Calibri;
        mso-bidi-font-family:"Times New Roman";}
@list l0:level2
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Courier New";}
@list l0:level3
        {mso-level-number-format:bullet;
        mso-level-text:\F0A7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Wingdings;}
@list l0:level4
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Symbol;}
@list l0:level5
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Courier New";}
@list l0:level6
        {mso-level-number-format:bullet;
        mso-level-text:\F0A7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Wingdings;}
@list l0:level7
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Symbol;}
@list l0:level8
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:"Courier New";}
@list l0:level9
        {mso-level-number-format:bullet;
        mso-level-text:\F0A7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        text-indent:-.25in;
        font-family:Wingdings;}
ol
        {margin-bottom:0in;}
ul
        {margin-bottom:0in;}
--></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>All<o:p></o:p></p><p class=MsoNormal>Attached are the minutes of the last two telephone calls (not including the one today during which these were approved for publication).<o:p></o:p></p><p class=MsoNormal>Ben<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b>Notes of meeting<o:p></o:p></b></p><p class=MsoNormal><b>CAB Forum <o:p></o:p></b></p><p class=MsoNormal><b>10 October  2013<o:p></o:p></b></p><p class=MsoNormal><b>Version 1<o:p></o:p></b></p><p class=MsoNormal><b>1.  Present:</b>   Ben Wilson, Stephen Davidson, Eddy Nigg, Rich Smith, Robin Alden, Eneli Kirme, Dean Coclin, Atsushi Inaba, Wayne Thayer, Mert Ozarar, Atilla Biler, Hävard Molland, Gerv Markham, Geoff Keating, Rick Andrews, and Jeremy Rowley <o:p></o:p></p><p class=MsoNormal><b>2.  Agenda review:</b> Eddy asked that the question regarding exceptions to migration to 2048-bit be discussed.  Ben asked that we add discussions about the meaning of EV and the definition of application service provider to the list.  Gerv asked to discuss a new working group on certificate format best practices.   <o:p></o:p></p><p class=MsoNormal><b>3.  Minutes:</b>  Ben explained that he hasn’t typed up the minutes of the telephone call on 19 Sept. 2013, but he will and circulate them soon. <o:p></o:p></p><p class=MsoNormal><b>4.  Ballots:  </b>Voting on Ballot 89 starts next Monday.  Anyone with comments to bring them to the list.  Other ballots need to be revisited and presented.  <b><o:p></o:p></b></p><p class=MsoNormal><b>5.  Membership applications:</b>   Dean noted that we’ve received the application from Atos.  They’ve signed the IPR Agreement and confirmed they meet the bylaws and have passed an audit report, but we are still unclear on whether they’ve issued any publicly trusted SSL certificates.  There is nothing under Atos in issuance databases, so it’s possible that they are listed under a different name.  Dean will go back to them and ask for a confirmation of this because this issue is similar to the reason why we held up the application of Affirm Trust.<o:p></o:p></p><p class=MsoNormal><b>6.  Bylaws:</b>  As noted in Dean’s email and the draft minutes of the Ankara face-to-face, we have discussed the participation levels of interested parties, invited guests, and others.  Dean quickly reviewed the proposed language.  Dean suggested that we circulate a ballot.  Ben offered to take the language and redline page 4 of the Bylaws and then circulate that page so everyone can see what the changes are.  Ben will take the action to mark up the bylaws.<o:p></o:p></p><p class=MsoNormal>Ben asked about the issue raised in Sigbjorn’s recent email about whether Opera met the definition of a browser.  Gerv clarified that the issue was the use of a definition for application software in the draft recommendations for processing EV certificates.  Turning to the definition of “browser” in the bylaws, however, we need to look at this in light of Oracle’s interest in joining the CABF.   The bylaws define “browsers” as someone who makes a browser product.  Who we’re talking about are not the root store operators, but also operating platforms in addition to software used for browsing.  Ben said we could add operating system to the title “Browser/OS”.  We might also have to consider the size of the applicant, but there might be small ones that want to join.  If they become a voting member, it might have an impact.  This is not trivial, we should take this to the list.  If they want to join, we should change the definition so that they fit.  Ben will start a thread on the list discussing this topic.<o:p></o:p></p><p class=MsoNormal><b>7.  Review of working group status:</b>  We are moving the revocation working group discussions to the main public list.  Dean said that for the code signing working group we had good discussion on the three areas we are focusing on--private key protection  (there really is an issue with theft and there have been examples of this previously), enhanced vetting, and information sharing.<o:p></o:p></p><p class=MsoNormal>Enhanced key protection with a hardware token or storage in a signing portal is the recommendation, but to implement such a drastic change, we might be upsetting current processes.  We will put recommendations out to the list for comments, then to the public for comment, and then we’ll have a phase in period over about a year.<o:p></o:p></p><p class=MsoNormal>Vetting:  This has been a concern primarily in the countries of China, Brazil, and Korea.  We’re recommending enhanced requirements similar to OV vetting for all of these.<o:p></o:p></p><p class=MsoNormal>Information sharing:  provisions for information sharing were preserved in the draft because we determined that because it was optional and not a requirement that it would not be opposed because if people wanted to share info, they can.<o:p></o:p></p><p class=MsoNormal>So we’ll be coming out with a draft of the code signing requirements.  First they’ll be reviewed by the Code Signing Group, and then for 30 days by the Forum, and then by the public for 60 days.   Before we set firm implementation dates, we’d like to get comments back and specifically target software developers and publishing houses and get their feedback on the draft.<o:p></o:p></p><p class=MsoNormal>EV Guidelines Working Group:  we are going to convert both EV Guidelines and Baseline Requirements to RFC 3647 format.  Jeremy has both drafts almost done, and by next call he might be able to distribute them.<o:p></o:p></p><p class=MsoNormal>New Working Group for Recommended Certificate contents:  Gerv proposed that a group be formed to address the various performance characteristics to optimize SSL system configuration so that handshakes and SSL communications are streamlined.  We should create a working group that gives all of the possibilities, and keeps track of progress on this topic, etc.  Mozilla and other people at the face-to-face exhibited interest in having the CAB Forum publish a set of best practices.  Ben offered to manage a new email list.  Wayne will set it up as cabfperf or performance mailing list.    <o:p></o:p></p><p class=MsoNormal>First we will need to follow the bylaws in setting up a working group.  According to section 5.3 of the bylaws, the process is to have a ballot to open up the working group.  Gerv will draft a ballot for the working group.<o:p></o:p></p><p class=MsoNormal><b>8. Review other tasks and follow-ups from Ankara meeting:   </b>We need to make sure we capture all tasks from the face-to-face.  Jeremy is mapping our guidelines to RFC 3647.  We were also going to distribute the ICANN presentation and other slides from the face-to-face. <o:p></o:p></p><p class=MsoNormal>For continued discussions on transitioning from SHA 1 we’ll need Tom to be present.  Microsoft was proposing some things that were more aggressive than what many of the CAs in the CAB Forum are ready to meet.  If those terms were accepted, then we would have a very short transition period.  At the F2F we talked about possible requirements to bring in the Baseline Requirement dates to match Tom’s dates, but we would like to propose to Microsoft that they move their dates to meet the CAB Forum dates because Microsoft’s dates are very aggressive.  <o:p></o:p></p><p class=MsoNormal>Rick would like to propose that all browsers agree on a certain policy versus every browser having its own implementation policies.<o:p></o:p></p><p class=MsoNormal>Gerv thinks it will be difficult to convince Microsoft to move its dates.  You might want to take advantage of the next three years and raise the bar for best practices of those certificates that could include shortening the life.<o:p></o:p></p><p class=MsoNormal>Wayne said he had reached out previously to Microsoft on this issue.  He also asked about the suggestion from the Munich face-to-face that we adopt a transition plan with SHA2 being offered as a default.  <o:p></o:p></p><p class=MsoNormal>Eddy said that defaulting to SHA2 will not work because as soon as customers get the SHA2 certificate they’ll be calling right back to get a new one that is SHA1 instead.  <o:p></o:p></p><p class=MsoNormal>Gerv said CAs should develop server patches that support multiple certificates with the ability to serve up different kinds of certificates based on browser capabilities.  <o:p></o:p></p><p class=MsoNormal>Ben asked whether we could create an FAQ about transitioning from SHA1 to SHA2.<o:p></o:p></p><p class=MsoNormal>Dean said the Microsoft was publishing an article, but if the article contains the deadlines, then we’d need to do something prior to that announcement.  By not publishing it, and keeping with the currently suggested deadlines, it could make things worse.  <o:p></o:p></p><p class=MsoNormal>Rick and Wayne will send a message to Tom to see if we can do anything about it and to see if there is an alternative path forward that lessens the impact.  <o:p></o:p></p><p class=MsoNormal><b>9.  Website status:</b>  Ben said that he broke all of the links trying to set up the pages as user-friendly permalinks, so he put them back to the way they were.  The re-indexing is not happening as it should, but he’ll get some help to figure it out.  Ben also asked Wayne whether we could copy all of the different versions of the Baseline Requirements and EV Guidelines from the docs folder over to the media folder so that all of the existing documents can be linked to from Wordpress.  Wayne said he thought it would be pretty easy.  Gerv said we need to make sure to create referral links from our existing URLs.  He also recommended that Ben prepare a punch list in order to delegate remaining tasks for the website.  <o:p></o:p></p><p class=MsoNormal><b>10.  Upcoming meetings:</b>  Our next call is October 24.  Then Nov 7, and it looks like we can keep on this schedule every other week into January next year.  We are looking at having our next face-to-face meeting in the San Francisco area the week of February 17 (the week before RSA).  Google is going to confirm.  For our June 2014 meeting, Eddy has offered to host in Israel.  The fall meeting will be hosted by WoSign in China and in 2015 we have offers from Microsoft, SwissSign to have it in Zurich, and e-tugra has offered to host in Istanbul in the fall of 2015.  Iņigio/Izenpe has also offered to host in Bilbao at some point in the future.  Code signing and EV working groups will meet next Wednesday and Thursday, respectively, and every other week after that.  <o:p></o:p></p><p class=MsoNormal><b>11.  Any Other Business:</b>  Eddy asked about providing a response to the question about exceptions to 1k certificate deadline.   Dean sent some questions last night to Eddy that can be used to ask in order to clarify the question more, because we need to understand that person’s issue a little better.   Discussion on the EV green bar can continue on the list.  <o:p></o:p></p><p class=MsoNormal><b>12.  Next call:  </b>October 24 <o:p></o:p></p><p class=MsoNormal>Meeting adjourned.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><b>- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -<o:p></o:p></b></p><p class=MsoNormal><b>Notes of meeting<o:p></o:p></b></p><p class=MsoNormal><b>CAB Forum <o:p></o:p></b></p><p class=MsoNormal><b>19 September  2013<o:p></o:p></b></p><p class=MsoNormal><b>Version 1<o:p></o:p></b></p><p class=MsoNormal><b>1.  Present:   </b>Dean Coclin, Mert Ozarar, Atilla Biler, Ben Wilson, Sigbjorn Vik, Eddy Nigg, Atsushi Inaba, Mads Henriksveen, Sissel Hoel, Rick Andrews, Geoff Keating, Robin Alden, Cornelia Enke, Jeremy Rowley, Gerv Markham<o:p></o:p></p><p class=MsoNormal><b>2.  Agenda:</b> Approved<o:p></o:p></p><p class=MsoNormal><b>3.  Minutes:</b>   Minutes from 5 Sept. 2013 approved. <o:p></o:p></p><p class=MsoNormal><b>4.  Discussion of Face-to-Face Meeting Agenda:  </b>  We should probably discuss a little about the NYT/Guardian article on NSA/GCHQ.  What is the global perspective on this?  Mads said that there was an article in the Norwegian paper recently.  It’s quite difficult for people like us representing important parts of the SSL ecosystem, to answer on behalf of all the people in the ecosystem.  How should these questions be answered?  Some statement from the Forum could be helpful for us.  The CA Security Council, and GlobalSign have written posts as a responses to this news.  These may all be good resources for others to use in response to the questions/concerns.    Besides that, our understanding is that CAs weren't really alleged to have been involved with the NSA spying, it was more software compromise and algorithms that might be compromised and this is what we are saying.  Geoff noted that more than one person is thinking that CAs are insecure, so some type of denial by the Forum would be smart.  Mads said a statement of what could be compromised rather than about CAs is a goo approach.   Ben will send out links to the posts. (Here they are:  (<a href="https://casecurity.org/2013/09/13/encryption-still-works-its-about-how-you-implement-it/#!">https://casecurity.org/2013/09/13/encryption-still-works-its-about-how-you-implement-it/#!</a> - <a href="https://www.globalsign.com/blog/trust-the-math-choose-your-friends-wisely.html">https://www.globalsign.com/blog/trust-the-math-choose-your-friends-wisely.html</a>)   From the inside we know, but for instance, in Norway, it might be more difficult to get that word out.  Mads, you could take these responses, and link to them if you need something to say that these are replies from the industry, maybe that will work.  It depends on how far you want to go, and how you want to respond.<o:p></o:p></p><p class=MsoNormal>Sigbjorn, Rick, Gerv and Connie:  There are issues raised by Bruce Schneier about whether or not we should raise key lengths or trust elliptic curves created with Dual EC_DRBG.    I think that was mainly in the context of a random number generator, not in certificates.  There was a random number generator that NSA had a hand in generating.    That was the Deterministic Random Bit Generator (DRBG) Algorithm.  That’s the first issue.  The second issue is that the constants (curves) for these standards may not be as quite as secure as we thought they would be.    <a href="https://www.schneier.com/blog/archives/2013/09/how_to_remain_s.html">https://www.schneier.com/blog/archives/2013/09/how_to_remain_s.html</a>  The issue is that because NSA had a hand in selecting the curves, there might be might an unknown weakness or backdoor for decryption.  The answer is that nobody uses DRBG, so the concern is only about the curves.  (Speculation is that they could have been favored based on brute force searching for constants with certain properties that would give the NSA a head start on being able to decrypt data that was encrypted by relying on such curves.)<o:p></o:p></p><p class=MsoNormal>Sigbjorn:  Another topic I’d like to discuss is that some CAs do everything for the customer, generate private key, public key, and send to customer encrypted.  If in this process the NSA is able to obtain the private key, they can then get to all of the communications.  Shouldn’t this be prohibited?<o:p></o:p></p><p class=MsoNormal>Eddy:  CAs should be allowed to provide this as an option for customers, otherwise you’ll have lots of support problems.<o:p></o:p></p><p class=MsoNormal>Connie:  This depends on the implementation and a consideration of the architecture of your backend systems and how you are doing this.  We should discuss this on Wednesday morning.  It could be a problem, because some customers might really want such a service.<o:p></o:p></p><p class=MsoNormal>Gerv:  Can the CAs that offer this answer what percentage of customers request that the CA generates the private key for them vs. those that only require a CSR?<o:p></o:p></p><p class=MsoNormal>Eddy:  The majority of our subscribers request that the private key be generated by the CA—for server certificates.  This might be around 70%. <o:p></o:p></p><p class=MsoNormal>Gerv:  Do you think that this is because generating it on the customer’s server is more complicated?<o:p></o:p></p><p class=MsoNormal>Eddy:  Yes.<o:p></o:p></p><p class=MsoNormal>Robin:  We don’t generate keys for our server certificates.  There are some clients that need us to generate client certificates for them.<o:p></o:p></p><p class=MsoNormal>Eddy:  We do just the opposite, because the browser software helps customers generate their own key pairs for SMIME.  <o:p></o:p></p><p class=MsoNormal>Gerv:  That would be an interesting topic to discuss.  <o:p></o:p></p><p class=MsoNormal>Ben:  Atsushi has requested that we talk about the use of SHA2 on mobile devices in Japan.<o:p></o:p></p><p class=MsoNormal>Atsushi:  Yes, I would like to address the issue of SHA2 in the Japanese market.  <o:p></o:p></p><p class=MsoNormal>Ben:   SHA2 can be discussed in the morning, and then the other topics on the schedule are collaboration with other groups (IETF, NIST, etc.) and then we’ll talk about interested party and observers.  There is an update from ICANN as well. <o:p></o:p></p><p class=MsoNormal>Finally, we have also invited the audit and supervisory groups of Turkey to attend the meeting as invited guests.  <o:p></o:p></p><p class=MsoNormal><b>5.  Any Other Business:</b>  None.<o:p></o:p></p><p class=MsoNormal><b>6. Next phone call:</b>   Thurs. October 10th.<o:p></o:p></p><p class=MsoNormal><b>7.  Meeting adjourned.<o:p></o:p></b></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>