<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: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: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;}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
        {mso-style-priority:34;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        margin-bottom:.0001pt;
        mso-add-space:auto;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
p.MsoListParagraphCxSpFirst, li.MsoListParagraphCxSpFirst, div.MsoListParagraphCxSpFirst
        {mso-style-priority:34;
        mso-style-type:export-only;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        margin-bottom:.0001pt;
        mso-add-space:auto;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
p.MsoListParagraphCxSpMiddle, li.MsoListParagraphCxSpMiddle, div.MsoListParagraphCxSpMiddle
        {mso-style-priority:34;
        mso-style-type:export-only;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        margin-bottom:.0001pt;
        mso-add-space:auto;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
p.MsoListParagraphCxSpLast, li.MsoListParagraphCxSpLast, div.MsoListParagraphCxSpLast
        {mso-style-priority:34;
        mso-style-type:export-only;
        margin-top:0in;
        margin-right:0in;
        margin-bottom:0in;
        margin-left:.5in;
        margin-bottom:.0001pt;
        mso-add-space:auto;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
span.apple-converted-space
        {mso-style-name:apple-converted-space;}
.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:952444416;
        mso-list-type:hybrid;
        mso-list-template-ids:568090908 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
        {mso-level-number-format:bullet;
        mso-level-text:\F0B7;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        margin-left:37.3pt;
        text-indent:-.25in;
        font-family:Symbol;}
@list l0:level2
        {mso-level-number-format:bullet;
        mso-level-text:o;
        mso-level-tab-stop:none;
        mso-level-number-position:left;
        margin-left:73.3pt;
        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;
        margin-left:109.3pt;
        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;
        margin-left:145.3pt;
        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;
        margin-left:181.3pt;
        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;
        margin-left:217.3pt;
        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;
        margin-left:253.3pt;
        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;
        margin-left:289.3pt;
        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;
        margin-left:325.3pt;
        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="#0563C1" vlink="#954F72">
<div class="WordSection1">
<p class="MsoNormal">Final Minutes for CA/Browser Forum Teleconference 22 December 2016 (approved 5 January 2017)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:10.0pt">Attendees:<span class="apple-converted-space"><span lang="EN"> </span></span><span lang="EN">Atsushi Inaba (Globalsign), Ben Wilson (Digicert),
</span>Dean Coclin (Symantec), <span lang="EN">Doug Beattie (Globalsign), Gervase Markham (Mozilla), JC Jones (Mozilla), Jeff Ward (BDO, for WebTrust), Ken Myers (US PKI), Kirk Hall (Entrust), Li-Chun Chen (Chunghwa Telecom), Peter Bowen (Amazon), Peter Miscovic
 (Disig), Rich Smith (Comodo), Rick Andrews (Symantec), Ryan Sleevi (Google), Tarah Wheeler (Symantec), Tim Shirley (Trustwave), Tyler Myers (GoDaddy), Wayne Thayer (GoDaddy)</span><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 – there were no changes to the Agenda.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">4.    Approve Minutes of teleconferences of Dec. 8, 2016.  The draft Minutes were approved for posting.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">5.    Discuss WebTrust issues (Jeff Ward, BDO, for WebTrust).  Kirk had invited Jeff Ward to participate on the call to discuss certain WebTrust audit questions that had arisen on the prior call.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Jeff first addressed BR WebTrust v2.1, effective for audit periods starting on or after Dec. 1, 2016, and available here:
<a href="https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.webtrust.org%2Fprinciples-and-criteria%2Fitem83172.aspx&data=01%7C01%7Cjfward%40bdo.com%7C917ef166c9824658a3e708d42ad70431%7C6e57fc1a413e405091da7d2dc8543e3c%7C0&sdata=j1gnAWt%2Bw1PFmRJMwznnxpDhye7dy%2BdTl8wHXIl1d2I%3D&reserved=0">
<span style="color:windowtext">http://www.webtrust.org/principles-and-criteria/item83172.aspx</span></a>.  Sec. 4.1 on Verification of Domain Control provides:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.25in">The CA maintains controls to provide reasonable assurance that as of the date the Certificate was issued, the CA obtains confirmation in accordance with the SSL Baseline Requirements Sections 3.2.2.4, 3.2.2.5,
 3.2.2.6 and 4.2.2 related to the Fully-Qualified Domain Name(s) (including wildcard domains and new gTLDs (generic top-level domains)) and IP address(es) listed in the Certificate.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Appendix D contains additional guidance:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.25in">Appendix D: CA/B Forum effective date differences<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.25in">SSL Baseline Requirements   <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.25in">The following Baseline Requirements have effective dates later than the effective date of these Audit Criteria.  Refer to details and instructions below for guidance on how to address these as part of an audit:
 ***<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.25in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.25in">Reference: 3.2.2.4 <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.25in">Effective Date: 1 March 2017 <o:p>
</o:p></p>
<p class="MsoNormal" style="margin-left:.25in">Guidance: <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.25in">Baseline Requirements v1.3.8 replaced the entirety of the domain validation requirements in this section with new requirements.
<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.25in">For certificates issued on or before 28 February 2017, the auditor is directed to consider the domain validation requirements in Section 3.2.2.4 of Baseline Requirements v1.3.7.
<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.25in">For certificates issued on or after 1 March 2017, the auditor is directed to consider the domain validation requirements in Section 3.2.2.4 of Baseline Requirements v1.4.1.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">This version of the BR WebTrust audit criteria is based on BR v1.4.1, which is complete through Ballot 175 and so includes Ballot 169 (effective March 1, 2017) that restricts domain validation to ten stated methods.  However, the BRs are
 being re-enacted through Ballots 180 – 182 to comply with the Forum’s IPR Policy.  Kirk pointed out that if Ballots 180 and 181 pass on January 7 but the vote on Ballot 182 is delayed while Exclusion Notices are examined by a Patent Advisory Group, then BR
 3.2.2.4 will be altered from what is was under Ballot 169 and the guidance under BR WebTrust v2.1, Appendix D will no longer be accurate.  Jeff was asked how auditors would deal with this.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Jeff said there would likely be a communication to auditors pointing out the change to the BRs since BR WebTrust v2.1 was adopted by WebTrust, and it was not likely that CAs would be held to the language of BR 3.2.2.4 as it existed under
 Ballot 169 starting on March 1, 2017.  The audit will only follow what the current BRs require of a CA at any given time.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Peter said that one browser had publicly stated that no matter what BR 3.2.2.4 said with modifications under Ballots 180 and 181 (which again allow CAs to use “any other method” for domain validation so long as the CA makes certain determinations),
 that browser expected CAs to limit themselves to the ten validation methods of Ballot 169 only.  He asked if WebTrust would follow this browser’s expectation when conducting BR audits on and after March 1.  Jeff said browser rules are important, but a BR WebTrust
 audit would be based on the BR WebTrust criteria which are based on the BRs.  It had happened before that the most current version of WebTrust audit criteria did not keep up with changes to the BRs or other CABF requirements.  The basic rule is that if a CA
 is in compliance with the then-current CABF requirements, that would control over any outdated WebTrust audit criteria. Since the WebTrust criteria are updated from time to time based on CABF requirements, auditors test for compliance with those requirements
 as referenced in the document (each updated version references what version of CABF criteria they are based on).   <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Gerv asked what would happen in the audit report if a CA was in compliance with applicable CABF requirements, but not in compliance with outdated WebTrust audit criteria – would the CA receive a clean (unqualified) audit report?  Jeff said
 different auditors might treat this differently (some might include a statement or observation to that effect in the report, known as an emphasis of matter in the audit report, others might not), but it would not cause an audit report to be qualified.  WebTrust
 will likely clarify Appendix D before March 1 to reflect any further changes to BR 3.2.2.4 in Ballots 180 or 181.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Peter again noted one browser’s expectation that CAs will limit themselves to only the ten methods of Ballot 169, so CAs may want to talk to root programs if they want to use another validation method. 
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Jeff noted that some Forum members had asked for changes to the Network Security requirements of the BR WebTrust audit criteria (e.g., as to days versus quarterly, etc.) to deal with potential ambiguities.  WebTrust was looking to the Forum
 to provide guidance as to the types of changes and clarifications they wanted in the Network Security audit criteria, as WebTrust could only act with guidance from the Forum. 
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Ben said DigiCert was conducting an internal review of the Network Security requirements and “red-lining” them in areas for possible simplification or clarification.  DigiCert will circulate the red-lined document when completed and get
 input from other members.  Peter noted that some auditors feel the Network Security audit language is unclear and should be changed, and there may be conflicting interpretations of current language from different auditors.  Jeff said WebTrust would be most
 comfortable making changes with guidance from the Forum on what revised standards it wanted incorporated.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Kirk asked Jeff what WebTrust criteria were under development.  Jeff said the Code Signing audit requirements [which are not based on a CABF document] were 90% complete and a draft would be released soon, and a version 1.6 of the EV Code
 Signing audit criteria (reformatted to RFC 3647 format) would become effective January 1, 2017.  WebTrust is also developing Practitioner Guidance intended to help new auditor practitioners conduct a WebTrust audit as well as provide clarification to experienced
 auditors on complex issues, and was also circulating a draft of criteria for WebTrust for RAs to deal with cases where external RAs are used and must be audited – this document is not as far along.  Many of the criteria for this document were taken from existing
 RA audit requirement in WebTrust for CAs where the CA itself performs the RA function.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Jeff then reported on the “continuity of audit period” issue that had come up at a recent WebTrust auditor meeting in San Francisco.  A standard practice among auditors when a client receives a qualified audit (i.e., fails to meet some
 criteria) was to give the client time to remedy the problems, then conduct a successful point-in-time audit, and only then re-start the period of time audits.  The reasoning is that clients who discover after the end of an audit period that they were not in
 compliance and receive a qualified audit showing a need to change procedures would not want to pay for a continuous period of time audit for the current audit period knowing it will again result in a qualified audit (at least to the date the problems were
 addressed and the point in time audit is passed).  As a result, there would not be continuous period of time audits for the client, but instead there would be a gap for the period from the end of the prior period of time audit to the time of a successful point
 in time, with no reporting on that gap period.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Four of the browsers attended the meeting and said they were not comfortable with this approach, but instead wanted continuous period of time audit reports, even if that meant there would be two back-to-back qualified audit reports for
 the reasons discussed above.  The browsers stressed they could often accept qualified audit reports so long as they know what the problems were, and that the problems were being remediated.  What they didn’t like was being in the dark during any gap period
 – what if additional problems arose during this gap period?  As a result, Jeff said WebTrust auditors represented by the WebTrust Committee, BDO, Deloitte, EY, and KPMG, were advised of this browser preference, and there would not be gap periods when a qualified
 audit arises.  <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Finally, Kirk recalled that a few years ago there had been discussion of getting WebTrust audit criteria updates on a regular 12-month cycle, e.g., as of July 1 of each year the existing CABF requirement would be noted and the corresponding
 WebTrust audit requirements would be updated through July 1, with the new criteria to be effective as of the following January 1.  Kirk recalled that one problem was that ETSI required a longer time for updates (e.g., 9 months).  He asked Jeff if WebTrust
 had considered any kind of regular annual audit criteria update cycle.  Jeff said WebTrust intended to focus on Forum requirements changes at its fall meeting each year to do updates to WebTrust audit criteria.  Kirk thanked Jeff for his contributions to the
 meeting.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">6.    Governance Change Working Group update.  Dean said the WG had met and hoped to complete edits to its proposal, but still had one section left to review at its next meeting.  After that, the proposal will be transmitted to the CABF
 for discussion.  The proposal does not contain actual Bylaw changes to accomplish the governance changes under discussion, but rather is a roadmap of detailed concepts so that the WG can get Forum feedback before doing the hard work of drafting new Bylaws,
 etc.  He hoped to finish the proposal early in January.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">7.    Validation Working Group update.  Kirk and Tarah provided an update.  The WG continues to work on draft ballots (many of which are listed below) to prepare them for the full Forum, including CNAME verification, amending methods for
 IP address verification, SRV names, RFC 822 Names and Other Names, and clarifications to the domain validation methods of BR 3.2.2.4 as passed by Ballot 169.  There was also a discussion of changing the BRs and EVGL to deal with countries that do not use state
 or province in addresses, as well as changing the EVGL for jurisdictions where different types of businesses are registered at different levels of government.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">8.    Policy Review Working Group update.  Ben said the WG is working on modifications to the BRs to clarify what is intended when the term “CA” is used, and a draft would be circulated soon.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">9.    IPR Policy Task Force update.  Kirk noted he had circulated Minutes for the most recent Task Force call.  In summary, he noted Virginia had presented a ballot concept that would have included a 7 day discussion period, 7 day straw
 ballot (to avoid possible IP fishing), a 30/60 day review period, and a 7 day voting period for final approval.  Several on the Task Force call had thought that process took too long for most ballots, which do not result in any Exclusion Notices.  As a result,
 Kirk though Virginia might be modifying the ballot concept so the 7 day straw vote before the IP review period might be treated also as the final approval vote if no Exclusion Notices were filed during the review period – but he wasn’t certain of the details. 
 Once consensus is achieved, the new voting rules can be adopted in a simple 14 day vote, as no IP review period in required for Bylaws changes, and new ballots can begin.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Kirk also noted that Ballots 180-182 were still proceeding and that if any members wanted to file Exclusion Notices, they must do so by December 31.  Peter noted only one CA had filed an Exclusion Notice for Ballot 182 to date, and asked
 if members needed to file again if they had previously filed similar Exclusion Notices in the past (e.g., for Ballot 169 earlier in the year).  Kirk said that in his personal opinion members who wanted to make sure their Exclusion Notices would be effective
 under the IPR Policy should refile them by December 31.  He also said members should make sure to use a form for their Notices like the template notice form he had circulated (as prior Notices might not be valid for a number of reasons, including the fact
 that no member had stated whether it was willing to license its IP, which was a requirement for Exclusion Notices under the IPR Policy).  [Members should consult their own IP counsel on all these points before proceeding.]<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">10.  Ballot Status.  Kirk noted the following ballots are underway (Ballots 180-182) or are in the queue waiting to begin:
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoListParagraphCxSpFirst" style="margin-left:37.3pt;mso-add-space:auto;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">      
</span></span></span><![endif]>Ballots 180-182 (Kirk, Virginia) – Review period ends 12/31/2016, voting starts 1/1/2017<o:p></o:p></p>
<p class="MsoListParagraphCxSpMiddle" style="margin-left:37.3pt;mso-add-space:auto;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">      
</span></span></span><![endif]>Ballot 176: BR 3.4.4.2 - CNAME verification (Jeremy)<o:p></o:p></p>
<p class="MsoListParagraphCxSpMiddle" style="margin-left:37.3pt;mso-add-space:auto;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">      
</span></span></span><![endif]>Ballot 179: BR 6.1.7 – Root signing time stamping certs (Dimitris)<o:p></o:p></p>
<p class="MsoListParagraphCxSpMiddle" style="margin-left:37.3pt;mso-add-space:auto;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">      
</span></span></span><![endif]>BR 7.1.3 : OCSP responder certs (Wayne) <o:p></o:p></p>
<p class="MsoListParagraphCxSpMiddle" style="margin-left:37.3pt;mso-add-space:auto;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">      
</span></span></span><![endif]>BR 7.1.4.2.2 and EVGL 9.2.5 and 9.2.7 (Li-Chun)<o:p></o:p></p>
<p class="MsoListParagraphCxSpMiddle" style="margin-left:37.3pt;mso-add-space:auto;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">      
</span></span></span><![endif]>SRV names in certificates (Jeremy)<o:p></o:p></p>
<p class="MsoListParagraphCxSpMiddle" style="margin-left:37.3pt;mso-add-space:auto;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">      
</span></span></span><![endif]>Reuse of domain validation data after Ballot 169 effective date (Wayne)<o:p></o:p></p>
<p class="MsoListParagraphCxSpMiddle" style="margin-left:37.3pt;mso-add-space:auto;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">      
</span></span></span><![endif]>RFC 822 Names and Other Names (Jeremy)<o:p></o:p></p>
<p class="MsoListParagraphCxSpLast" style="margin-left:37.3pt;mso-add-space:auto;text-indent:-.25in;mso-list:l0 level1 lfo1">
<![if !supportLists]><span style="font-family:Symbol"><span style="mso-list:Ignore">·<span style="font:7.0pt "Times New Roman"">      
</span></span></span><![endif]>CAA (Gerv) – see prior CAA topic<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.3pt"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:1.3pt">He said he believed the voting procedures for new ballots would be agreed upon soon and would only take 14 days for approval in a CABF ballot, and so he encouraged members to get their ballots ready for introduction
 and discussion to clear the backlog.<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:1.3pt"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:1.3pt">11. CT Policy Days Update.  This meeting is being organized by Ryan Hurst in Mountain View, CA in February for one of these dates: Feb. 7-8, Feb. 20-21, or Feb. 21-22.  Tarah and others asked if a date had been
 chosen yet, as members need to know the date soon for calendar planning purposes.  Kirk said he would email Ryan to ask if the meeting date had been decided.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">12.  Next F2F meetings:  Kirk noted that hotel information had been added to the wiki for the March meeting in Research Triangle Park, NC, and recommended members make their reservations and also add their names to the list of attendees
 on the wiki for the meeting.  Gerv said new information had been added to the wiki as to shuttles available from the airport to the hotel.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Kirk asked Dean about the status of the date poll he had published on the proposed June 20-22 dates for the meeting in Berlin.  Dean said 25 members had already indicated they were available on those dates, and the host said other dates
 in June may not be available, so that meeting will be set for June 20-22.  The upcoming meeting dates are therefore as follows.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:27.0pt;text-indent:-9.0pt">21-23 March 2017 – Research Triangle Park, NC (Cisco)
<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:16.7pt">20-22 June 2017 Berlin (D-Trust) <o:p>
</o:p></p>
<p class="MsoNormal" style="margin-left:16.7pt">3-5 Oct 2017 (Chunghwa Telecom)<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">13.  Any Other Business.  Mozilla CT Policy: Kirk noted there had been discussion about Mozilla’s CT policy on the Mozilla list, and asked Gerv if he wanted to provide any update.  Gerv recommended that people read the draft policy carefully
 as a whole, and respond to the policy as a whole, and not just parts.  The discussion will continue, and the policy is not likely to be finalized for weeks or even months.  Mozilla is open to suggestions of new goals and draft details in the policy, as its
 position is not yet fixed.  <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Kirk asked if a revised draft would be released soon based on comments to date, and Gerv said probably not until the new year.  He noted that he had posited a “thought experiment” to the group on the Mozilla CT list – what would the pros
 and cons be of requiring all CT logs to accept all certificates for logging – is that a good idea, or not, and why?  He would appreciate responses from members on this concept.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Kirk asked if Mozilla was planning to coordinate its acceptance on new CT logs with others who have CT programs, such as Google.  Gerv said the Mozilla CT policy would be independent, and would always be open and transparent, but was likely
 to incorporate the Google list of accepted CT logs as a starting point.  But the two programs would not otherwise be strictly linked.  By keeping its CT policy open and transparent, other programs will be able to copy the program and Mozilla’s list of approved
 CT logs if they desire, just as occurs with Mozilla’s root program today.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">There was no other business.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">14.  Next call on Thursday, Jan. 5, 2017 <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">15.  Adjourn<o:p></o:p></p>
</div>
</body>
</html>