<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=us-ascii"><meta name=Generator content="Microsoft Word 15 (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:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:#0563C1;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:#954F72;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@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="#0563C1" vlink="#954F72"><div class=WordSection1><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Minutes September 15, 2016<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Attendees: <span lang=EN style='color:black'>Alex Wight (Cisco), Atsushi Inaba (Globalsign), Ben Wilson (Digicert), Bruce Morton (Entrust), Carolyn Oldenberg (Globalsign), </span><span style='color:black'>Curt Spann (Apple), Dean Coclin (Symantec), </span><span lang=EN>Dimitris </span>Zacharopoulos (Harica), <span lang=EN style='color:black'>Doug Beattie (Globalsign), Erwann Abalea (DocuSign), Jody Cloutier (Microsoft), Josh Aas (Let’s Encrypt), Ken Myers (US PKI), Kirk Hall (Entrust), Li-Chun Chen (Chunghwa Telecom), </span>Mads Henriksveen (BuyPass), <span lang=EN style='color:black'>Patrick Tronnier (OATI), Peter Bowen (Amazon), Peter Miscovic, (Disig), Phillip Hallam-Baker (Comodo), Ryan Sleevi (Google), Tim Shirley (Trustwave), </span>Virginia Fournier (Apple), <span lang=EN style='color:black'>Wayne Thayer (GoDaddy), Wendy Brown (FPKI).<o:p></o:p></span></p><p class=MsoNormal style='mso-margin-top-alt:1.0pt;margin-right:0in;margin-bottom:1.0pt;margin-left:0in'><o:p> </o:p></p><p class=MsoNormal style='mso-margin-top-alt:1.0pt;margin-right:0in;margin-bottom:1.0pt;margin-left:0in'>(Vice Chair Kirk Hall presided because Chair Dean Coclin was in a location where he could listen only.)<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:1.0pt;margin-right:0in;margin-bottom:1.0pt;margin-left:0in'><o:p> </o:p></p><p class=MsoNormal>1. Roll Call<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>2. Read Antitrust Statement <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>3. Review Agenda – no changes<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>4. Approve Minutes of Sept. 1<sup>st</sup> – Kirk asked if there were any edits to the draft minutes. There were no edits, and so the minutes of September 1 were approved and will be posted to the public list.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>5. Ballot Status<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>(a) Ballot 175 – Addition of given name – Kirk stated that Ballot 175 on given names had passed on September 8.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>(b) Miscellaneous edits to Ballot 169. Kirk noted that several members had noticed small typos in Ballot 169 as enacted, and had suggested corrections. Ben said he planned to make the corrections soon. Peter suggested maybe this issue of corrections should be delayed until after discussion of the IPR policy and our future plans on making any corrections. Gerv recalled that in the past we had some ballot language somewhere that gave the authors of ballots editorial discretion to correct errors, and that might apply here. Kirk stated that he had previously proposed amending the bylaws to allow something like a “consent ballot” where minor corrections like this would be formally proposed to the members, and then if no one objected within a certain period (e.g., 7 days), the corrections would be made. He thought a somewhat more formal process with a record of our actions would be better than simple ad hoc corrections with no record. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>(c) OID needed for Test Certificate under Ballot 169. Dimitris pointed out that the new definition of Test Certificate under Ballot 169 called for the CA to include “a critical extension with the specified Test Certificate CABF OID” in the Test Certificates. Kirk asked if this was meant to be a single Test Certificate OID used by all CAs, or one unique to each CA. Dimitris said the natural interpretation was a single CABF OID used by all CAs, and thought the Validation Working Group should get an OID assigned. Doug agreed. Kirk noted the Validation Working Group recently became inactive, but that he would talk to Jeremy Rowley about scheduling new meetings.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>(d) Updating BR 3.2.2.5 (IP Address verification) to match Ballot 169. Doug had sent an email suggesting the validation methods for IP addresses in BR 3.2.2.5 be updated as appropriate to match the new validation methods for domain names in BR 3.2.2.4. Gerv agreed, and suggested the issue be sent to the Validation Working Group. Kirk will make this request to Jeremy Rowley, who was not on the call.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>(e) Draft Ballot 176 – Addition of CNAME verification to domain validation methods. Kirk noted that Jeremy had suggested amending BR 3.2.2.4 to allow authentication of domain names by CNAME. Jeremy was not on the call, but Kirk noted there had been discussion by email of Jeremy’s draft proposal, and asked if members were close to a resolution. Ryan said that Jeremy’s proposal was good, and Peter proposed some improvements. We are now waiting for Jeremy’s revised proposal before proceeding.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>(f) Draft SRV names ballot. Jeremy has also proposed a ballot allowing SRV names in certificates, but because he was not on the call, there was no update.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>6. Miscellaneous topics:<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>(a) Inadvertent domain validation by email scanning applications. Peter pointed out by email that some email scanning applications click on links in emails to check for malware, and that any CA using the email validation method and confirming domain ownership or control via a simple one-click on a link in an email could end up with inadvertent domain validation when no person had actually clicked on the link to confirm. The better option is to require a second step, such as directing the subscriber to a page where another button had to be clicked to prove domain control, requiring the subscriber to copy and paste the Random Value in a field and send it back to the CA, etc. Kirk asked Peter if he wanted to propose a ballot to require steps by CAs to avoid inadvertent validation by email scanning applications.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Peter, Phillip, and Dimitris discussed various technical methods that might help prevent inadvertent validation. Peter said he didn’t think every possible danger needed to be addressed in the BRs, and simply wanted to alert CAs to this possibility. Dimitris said a BR requirements might not be auditable, and it might be better to post an article on the CABF website concerning “best practices” in this area.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>(b) Continuing the discussion on CAA. Rick Andrews had asked by email what the next steps should be for CAA, but Rick was not on the call so the discussion was postponed.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal style='text-autospace:none'>(c) Questions regarding timestamping certificates. Dimitris noted that BR 6.1.7 prohibits CAs from signing certificates with root CA private keys, except for five specified exceptions. Exception (3) allows signing the following types of certificates with a root “Certificates for infrastructure purposes (e.g. administrative role certificates, internal CA operational device certificates, and OCSP Response verification Certificates).” Dimitris asked whether time stamping certificates qualified as “infrastructure purposes” and could be signed by a root. (CAs must operate an RFC-3161-compliant Timestamp Authority using a time stamping certificate under Sec. 16.1 of the Code Signing Minimum Requirements, which is not a CABF document.) He thinks the current BR language is ambiguous.<o:p></o:p></p><p class=MsoNormal style='text-autospace:none'><o:p> </o:p></p><p class=MsoNormal style='text-autospace:none'>Bruce thought it was a bad practice to issue time stamping certificates directly from a root, and said that exception (3) could be amended to specifically disallow them, or we could remove all examples from exception (3). Peter noted that there may be some systems that “expect” a time stamping certificate to be signed by a root. Bruce said he would be surprised if it required the root to be a publicly trusted root for TLS certificates.<o:p></o:p></p><p class=MsoNormal style='text-autospace:none'><o:p> </o:p></p><p class=MsoNormal style='text-autospace:none'>Wendy noted that because code signing certificates require a time stamping service, would there be the same objection to signing a time stamping certificate from a root if the root were not publicly trusted. Dimitris said that issue probably should not be decided by this Forum, as some key players in code signing certificates are not Forum members. The Forum only has jurisdiction over SSL certificate issues.<o:p></o:p></p><p class=MsoNormal style='text-autospace:none'><o:p> </o:p></p><p class=MsoNormal style='text-autospace:none'>Bruce said members should look at the Code Signing Minimum Requirements document again – that document has all the specifications needed on this issue. Dimitris said that was not a complete solution, as he has seen some code signing certificate implementations that include a time stamping certificate that was signed by a publicly trusted SSL root. He thinks that’s a bad idea, and should not be allowed by exception (3) of BR 6.1.7.<o:p></o:p></p><p class=MsoNormal style='text-autospace:none'><o:p> </o:p></p><p class=MsoNormal style='text-autospace:none'>Peter noted that the current BR 6.1.7(3) language could be interpreted to allow this practice, and asked if the language should be amended to prohibit it. Dimitris noted the current language already allows for OCSP response verification certificates to be signed by trusted roots. Peter noted that exception (5) for existing infrastructure situations had effectively expired as of June 30, 2016.<o:p></o:p></p><p class=MsoNormal style='text-autospace:none'><o:p> </o:p></p><p class=MsoNormal style='text-autospace:none'>Ben asked what a CA would do if it wanted a time stamping certificate to be signed by a root. Peter said the CA could either sign the time stamping certificate from a sub-root of the trusted root, or sign from a non-trusted root. But he noted that signing a time stamping certificate from a trusted root does not appear to be a prohibited practice under the BRs today.<o:p></o:p></p><p class=MsoNormal style='text-autospace:none'><o:p> </o:p></p><p class=MsoNormal style='text-autospace:none'>Dimitris reiterated that he believes signing a time stamping certificate by a trusted root should not be allowed under the BRs, and exception (3) of BR 6.1.7 should be amended to prohibit the practice. Bruce asked the question whether time stamping certificates qualified as “infrastructure” under exception (3), and said it seemed not. However, OCSP Response verification Certificates did seem like “infrastructure” that would qualify for exception (3). Dimitris said he would draft a ballot to prohibit signing of time stamping certificates by trusted roots.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>7. Governance Change Working Group update. Ben said the working group had met by teleconference on September 13, and was still working on a number of open issues remaining from the draft governance change proposal discussed on the last CABF call. These issues included a discussion of the meaning of “affiliates” and how the IPR policy would apply to affiliates, and also whether the IPR policies would apply to all forms of participation in working groups or subcommittees, or not apply in certain limited cases where it’s not clear at the start that any proposals will result that could involve IP. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Virginia said the working group had a difference of opinion on this point, and she believes the IPR policy should strictly apply to all involvement in a particular working group or its subcommittees – that’s how the W3C IPR policy applies. If the IPR policy doesn’t apply at the start of a discussion, but the discussion soon turns to a proposal involving IP, then the members can never know for sure if they will be protected by the IPR policy and receive a royalty free license. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Ben noted that the IPR Policy the Forum has today applies to all activities, so what Virginia describes is what we have now. Peter noted that under the draft proposal, members must clearly join a working group and any of its subcommittees to contribute, and at that point the IPR Policy will apply in all cases – there would be no way to create a subcommittee with no coverage by the IPR Policy. In further discussion, it was explained that the IPR Policy would only apply to members of each relevant working group, and that the working group output would not be voted on or approved by other members not on the working group so they would not be bound by the working group IPR Policy.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>The next meeting of the Governance Change Working Group will be on September 27.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>8. Validation Working Group Status. Kirk noted that Jeremy Rowley had suspended further meetings of the Validation Working Group after the passage of Ballot 169, but it would have to be restarted to deal with the new issues raised on the call today. He will talk to Jeremy.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>9. Policy Review Working Group. Ben said the Policy Review Working Group was reviewing other standards to see if the Forum should adopt additional requirements to strengthen CAs. At present the working group is reviewing all the places in the BRs where the words “CA” and “Root CA” are used to find multiple meaning for the terms, and perhaps adopt new terms for clarity. Dimitris said that “Root CA” generally means an organization that functions as a certification authority, and “root certificate” generally means an X509 certificate, but not always, which can be confusing. The working group will come back with a proposal.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>10. Application of current IPR policy. Virginia discussed a presentation she had sent to members on what the Forum’s IPR Policy currently requires. In essence, the forum should prepare new or amended guidelines in the following order: (1) circulate draft ballots adopting or amending guidelines, (2) send out 30 or 60 day Review Notices so that members can identify any conflicting IP by means of filing Exclusion Notices, and (3) proceed to a vote on the ballot if no Exclusion Notices are received. If Exclusion Notices are received, then the Forum should appoint a Patent Advisory Group (PAG) to consider possible modifications to the draft ballot, workarounds, etc., after which a vote may be held. The Forum should follow this sequence exactly to get the benefits and protections of the IPR Policy.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Kirk then stated that he and Dean would be forwarding a detailed memo on this subject shortly outlining how the Forum can readopt its current guidelines to be in compliance with the IPR Policy. Peter noted that the members had voted on Ballot 169 and received two Exclusion Notices after the ballot, which meant that members did not know of the exclusions when voting – but members should have been aware of the Exclusion Notices before voting under our IPR Policy. Virginia stated we would likely need to form a PAG to evaluate the Exclusion Notices received. Kirk said there was some question of whether any past ballots had been finally adopted by the Forum, as we had not always sent out Review Notices and we had not held votes after the Review Notice period expired. Virginia stated that all members were now on notice of possible patent infringement claims relating to the Exclusion Notices filed for Ballot 169 on domain control, and should be aware of that when using any domain validation methods. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>11. Voting implications after CA or browser merger. Kirk noted that there were some pending mergers of CAs or browsers, and this presented the question of whether both merged companies should still vote in the Forum (or instead only one vote should occur). He noted that Bylaw 2.2(b) says “Only one vote per Member company shall be accepted; representatives of corporate affiliates shall not vote.” Gerv said that Mozilla had outlined the relationship between WoSign and StartCom based on public documents in a posting, and suggested members could see the details for themselves. He noted that the Forum’s IPR Policy has a definition of “affiliate”, and asked if the Bylaws had one. <o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>Peter noted that the same issue could arise from the pending merger of Opera and Qihoo 360 once the transaction has closed. He also stated that in some cases a CA and a browser could be affiliated – Amazon has a CA division, and a separate Silk browser division, for example (which are separate legal entities under common Amazon ownership). Kirk suggested this issue should be referred to the Governance Change Working Group for proposals.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>12. Ballot 177 – Election of Chair. Kirk noted that voting started today for election of a new Chair, and that the candidates were Ben Wilson and Kirk Hall. Voting will end on 9/22/16. Dean has outlined the procedure for members to submit their votes by separate email to Don Sheehy and Clemens Wanko who will tabulate the votes and announce the result.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>13. Ballot 178 – Election of Vice Chair. Kirk noted that the nomination period for Vice Chair opened a week ago, and would close that day. So far there were two nominees: Ben Wilson and Phillip-Hallam Baker. Election statements from the candidates are due by 9/22/2016.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>14. Any Other Business – Kirk noted that the registration list for the Fall Meeting in Redmond, WA (Oct. 18-20) was closed, but Dean and Jody have a waiting list, if anyone else is interested. He said that Dean and Jody had called for Agenda items.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>15. Next Forum teleconference on Sept. 29<sup>th</sup><o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>16. Adjourn<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal><o:p> </o:p></p></div></body></html>