<html>
<head>
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p><font face="Calibri">One question to Google people regarding this
line of the minutes:</font></p>
<p><font face="Calibri">
<blockquote type="cite"><span style="color:black">- Q re CT: Is
April finalized? A: CT policy days will finalized the exacts
dates</span></blockquote>
</font></p>
<p>Any update on that? I gather that the next CT policy days event
was due to be held in November 2017, but I cannot find information
on it.<br>
</p>
<p>Adriano</p>
<p><br>
</p>
<br>
<div class="moz-cite-prefix">Il 30/12/2017 03:08, Kirk Hall via
Public ha scritto:<br>
</div>
<blockquote type="cite"
cite="mid:ca5456f6726a4abda3c21fd9ccde30a0@PMSPEX03.corporate.datacard.com">
<meta http-equiv="Content-Type" content="text/html;
charset=windows-1252">
<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-top:0in;
margin-right:0in;
margin-bottom:8.0pt;
margin-left:0in;
line-height:105%;
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;}
/* List Definitions */
@list l0
{mso-list-id:137721671;
mso-list-template-ids:1244546180;}
@list l0:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1
{mso-list-id:362052088;
mso-list-template-ids:-246882662;}
@list l1:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l1:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l1:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l1:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l2
{mso-list-id:456146916;
mso-list-template-ids:-2132921218;}
@list l2:level1
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level3
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level4
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level6
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level7
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l2:level9
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l3
{mso-list-id:488522347;
mso-list-template-ids:1803192182;}
@list l3:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l3:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l3:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l3:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l3:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l3:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l3:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l3:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l3:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l4
{mso-list-id:495655091;
mso-list-template-ids:-1688431460;}
@list l4:level1
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4:level3
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4:level4
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4:level6
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4:level7
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l4:level9
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l5
{mso-list-id:524291550;
mso-list-template-ids:1218325648;}
@list l5:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l5:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l5:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l5:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l5:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l5:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l5:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l5:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l5:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l6
{mso-list-id:542443683;
mso-list-template-ids:435093082;}
@list l6:level1
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level3
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level4
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level6
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level7
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l6:level9
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l7
{mso-list-id:554898041;
mso-list-template-ids:-633317838;}
@list l7:level1
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l7:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l7:level3
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l7:level4
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l7:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l7:level6
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l7:level7
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l7:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l7:level9
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l8
{mso-list-id:568463265;
mso-list-template-ids:-1468642564;}
@list l8:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l8:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l8:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l8:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l8:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l8:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l8:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l8:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l8:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l9
{mso-list-id:805008084;
mso-list-template-ids:55064520;}
@list l9:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l9:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l9:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l9:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l9:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l9:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l9:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l9:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l9:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l10
{mso-list-id:846746215;
mso-list-template-ids:559075506;}
@list l10:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l10:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l10:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l10:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l10:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l10:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l10:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l10:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l10:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l11
{mso-list-id:846871687;
mso-list-template-ids:-1786713416;}
@list l11:level1
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l11:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l11:level3
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l11:level4
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l11:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l11:level6
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l11:level7
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l11:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l11:level9
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l12
{mso-list-id:922567638;
mso-list-template-ids:1002866604;}
@list l12:level1
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l12:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l12:level3
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l12:level4
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l12:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l12:level6
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l12:level7
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l12:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l12:level9
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l13
{mso-list-id:1074545433;
mso-list-template-ids:-1331809524;}
@list l13:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l13:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l13:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l13:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l13:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l13:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l13:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l13:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l13:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l14
{mso-list-id:1316179493;
mso-list-template-ids:1017133998;}
@list l14:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l14:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l14:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l14:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l14:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l14:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l14:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l14:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l14:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l15
{mso-list-id:1336609624;
mso-list-template-ids:-1105701380;}
@list l15:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l15:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l15:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l15:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l15:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l15:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l15:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l15:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l15:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l16
{mso-list-id:1366368766;
mso-list-template-ids:-1758719876;}
@list l16:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l16:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l16:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l16:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l16:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l16:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l16:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l16:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l16:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l17
{mso-list-id:1367177401;
mso-list-template-ids:1775522256;}
@list l17:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l17:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l17:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l17:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l17:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l17:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l17:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l17:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l17:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l18
{mso-list-id:1579168678;
mso-list-template-ids:1032614706;}
@list l18:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l18:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l18:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l18:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l18:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l18:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l18:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l18:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l18:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l19
{mso-list-id:1873301678;
mso-list-template-ids:-1265755906;}
@list l19:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l19:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l19:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l19:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l19:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l19:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l19:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l19:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l19:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l20
{mso-list-id:1961063582;
mso-list-template-ids:1337506214;}
@list l20:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l20:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l20:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l20:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l20:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l20:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l20:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l20:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l20:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l21
{mso-list-id:2060321254;
mso-list-template-ids:256028472;}
@list l21:level1
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l21:level2
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l21:level3
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l21:level4
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l21:level5
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l21:level6
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l21:level7
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l21:level8
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l21:level9
{mso-level-number-format:alpha-lower;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;}
@list l22
{mso-list-id:2120752805;
mso-list-template-ids:-1775315516;}
@list l22:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l22:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l22:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l22:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l22:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l22:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l22:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l22:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l22:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l23
{mso-list-id:2123063469;
mso-list-template-ids:1025830776;}
@list l23:level1
{mso-level-number-format:bullet;
mso-level-text:\F0B7;
mso-level-tab-stop:.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Symbol;}
@list l23:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:1.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:"Courier New";
mso-bidi-font-family:"Times New Roman";}
@list l23:level3
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:1.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l23:level4
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l23:level5
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:2.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l23:level6
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l23:level7
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:3.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l23:level8
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.0in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
font-family:Wingdings;}
@list l23:level9
{mso-level-number-format:bullet;
mso-level-text:\F0A7;
mso-level-tab-stop:4.5in;
mso-level-number-position:left;
text-indent:-.25in;
mso-ansi-font-size:10.0pt;
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]-->
<div class="WordSection1">
<p class="MsoNormal">The CA/Browser Forum was delayed in
completing the minutes for its last Face-to-Face meeting Oct.
4-5, 2017 in Taipei, and the proposed final Minutes were only
sent by the Chair to the Members on December 13, 2017 for
their review. There was not enough time for Members to review
the draft before the next teleconference of December 14, and
the teleconference of December 28 was cancelled due to the
holidays. The next Forum teleconference is scheduled for
January 11, 2018.<o:p></o:p></p>
<p class="MsoNormal">To avoid further delay in publishing the
Final Minutes on the Public list, we are following Bylaw
5.1(a) which states that draft Minutes will be considered
final two weeks after publication to the members, at which
point they will be considered final and be posted to the
Public list. The only edits offered during this two week
review period were from the Mozilla representative, and the
edits related solely to Mozilla’s presentation during the
meeting and so were accepted.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<b><span style="color:black">Final Meeting 42 Minutes – F2F
meeting, Taipei, Oct. 4-5, 2017</span></b><span
style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<b><span style="color:black">Attendance:</span></b><span
style="color:black"> Peter Bowen (Amazon); Geoff Keating and
Curt Spann (Apple); Jeremy Shen (Central Police University);
Franck Leroy (Certinomis / Docapost); Wayne Chan and
Sing-man Ho (Certizen Limited); Wen-Cheng Wang, Bon-Yeh Lin,
Wen-Chun Yang, Jenhao Ou, Wei-Hao Tung, Chiu-Yun Chuang,
Chung-Chin Hsiao, Chin-Fu Huang, Li-Chun Chen, Pin-Jung
Chiang, and Wen-Hui Tsai (Chunghwa Telecom); Alex Wight and
JP Hamilton (Cisco), Robin Alden (Comodo), Gord Beal (CPA
Canada), Ben Wilson and Jeremy Rowley (DigiCert), Arno
Fiedler and Enrico Entschew (D-TRUST); Kirk Hall (Entrust
Datacard); Ou Jingan, Zhang Yongqiang, and Xiu Lei (GDCA);
Atsushi Inaba and Giichi Ishii (GlobalSign); Wayne Thayer
(GoDaddy); Devon O'Brien (Google); David Hsiu (KPMG); Mike
Reilly (Microsoft); Gervase Markham and Aaron Wu (Mozilla);
Hoang Trung La (National Electronic Authentication Center
(NEAC) of Vietnam); Tadahiko Ito (Secom Trust Systems); Leo
Grove and Fotis Loukos (SSL.com); Brian Hsiung (Sunrise CPA
Firm); Steve Medin (Symantec); Frank Corday and Tim
Hollebeek (Trustwave); Robin Lin, David Chen, and Huang Fu
Yen (TWCA); and Don Sheehy and Jeff Ward (WebTrust).<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<b><span style="color:black">Antitrust Statement</span></b><span
style="color:black"> - Read by Robin Alden<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<b><span style="color:black">Mozilla Root Program Update -
Gerv</span></b><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Notetaker: Jeremy<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">1. Mozilla root policy 2.5 shipped.
Anyone wth questions should ask Mozilla.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">2. All s/MIME intermediate
certificates must have true technical constraints by Nov 15
2017. Revocation of non-compliant intermediates must happen
by April 15, 2018.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">3. Non-BR cert and OCSP issues. Lots
of reports of non-compliance with public thanks to Ryan and
other reports. Mozilla looks at the severity of the problem
along with the speed, openness, depth, and competence when
deciding what to do. Part of the remedial action is to
integrate checks into the issuance process that evaluate
compliance prior to issuance. Mozilla is debating whether
there will be a requirement for programmatic checking added
to the Mozilla policy.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">4. BR self-assessment. Mozilla may
require CAs to perform a Self-Assessment to surface
additional compliance issues. This is just a proposal at
this point. Feedback is welcome. One assessment would be
required for each CP/CPS pair.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">5. CAA and CNAME. Mozilla permits
the errata and non-errata checking. The expectation is all
CAs will migrate to the errata within the next three months
</span>after the ballot requiring use of the errata is passed
by the CAB Forum<span style="color:black">.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">6. ONECRL. The process for adding
intermediates to OneCRL is established. Mozilla adds a batch
of non-urgent updates every 2 weeks. Mozilla will make more
urgent updates as needed. OneCRL is only checked for TLS
(and is not checked for s/MIME). CAs can add their legacy
non-constrained CAs to avoid BRs. However, this is only
appropriate for legacy intermediates. New intermediates must
be technically constrained. Be sure to test the
certificate's serial number before it is marked as revoked
in CCADB. Many intermediates have similar names.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">7. CA Communication. The next CA
communication will occur in the Nov/Dec timeframe. The
communication will include administrative notices,
self-assessments, a request for CAA identifiers, a CABlint
requirement, and refinements to the problem reporting
mechanism. All CAs are expected to have at least one CAA
identifier. There will be penalties for failing to add
intermediates to CCDAB within the one week requirement.
Mozilla is pondering whether each CA should provide an email
mechanism for communications. Gerv will make a note to alter
the report to spam proof the email addresses.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">8. Aaron Wu is working towards
getting all BR self-assessments completed. Aaron will let
CAs know if further information is needed. Only after Aaron
completes his review does a CA move to the public discussion
phase.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">9. Firefox changes. Firefox 58 will
print warnings to the developer console for Symantec-rooted
EE certs if the notBefore date is before June 2016. Firefox
60 will disable all these certs (due out in May 2018).
Firefox 57 will include the first ever formally verified
cryptographic primitive in a major browser. The
implementation uses Curve25519 for key establishment. Gerv
will consult with Firefox team to discuss when they will
extend permitted keys to include 25519.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<b><span style="color:black">Microsoft Root Program Update -
Mike</span></b><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Notetaker: Robin<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Team updates: * Keri Street no
longer with Microsoft<o:p></o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l15
level1 lfo1;background:white">
Karina Sirota hired a few weeks ago<o:p></o:p></li>
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l15
level1 lfo1;background:white">
should be used for communications to ensure timely response.
Communications to CAs will come from this address as well
rather than from individual team members<o:p></o:p></li>
</ul>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Microsoft Trusted Root Program
releases through Windows Update: * Most recent release had
43 changes. Details at </span><a
href="http://aka.ms/rootupdates" moz-do-not-send="true"><span
style="border:none windowtext 1.0pt;padding:0in">http://aka.ms/rootupdates</span></a><span
style="color:#0044AA;border:none windowtext
1.0pt;padding:0in">.</span><span style="color:black"> Highlights:<o:p></o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l1
level1 lfo2;background:white">
This release will “<span style="color:windowtext"><a
href="https://www.cabforum.org/wiki/NotBefore"
moz-do-not-send="true"><span
style="color:#666666;border:none windowtext
1.0pt;padding:0in">NotBefore</span></a></span>” 6
WoSign/Startcom roots per <span style="color:windowtext"><a
href="https://blogs.technet.microsoft.com/mmpc/2017/08/08/microsoft-to-remove-wosign-and-startcom-certificates-in-windows-10/"
moz-do-not-send="true"><span
style="color:#0044AA;border:none windowtext
1.0pt;padding:0in">Windows Security Blog</span></a></span><o:p></o:p></li>
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l1
level1 lfo2;background:white">
Next release targeted for end of November 2017<o:p></o:p></li>
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l1
level1 lfo2;background:white">
Govt Domain constraints: technical solution pushed out to
latter half of CY18<o:p></o:p></li>
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l1
level1 lfo2;background:white">
Continued efforts toward automation of program processes to
minimize errors and enable increased verification of program
compliance<o:p></o:p></li>
</ul>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Update on our Common CA Data Base CA
Audit Letter Validation project (Jixi) * Purpose: CA Audit
Letter Validation using Natural Language Processing. Accept
requests from Salesforce to validate CA audit letter and
pass results back<o:p></o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l9
level1 lfo3;background:white">
Status: Connected to CCADB Prod for testing and bug fix
phase<o:p></o:p></li>
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l9
level1 lfo3;background:white">
Demo at next f2f (March 2018 in Virginia)<o:p></o:p></li>
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l9
level1 lfo3;background:white">
Daju project: Increase automation of the process of
ingesting CA changes and delivering the bits needed to
deploy the changes as part of our Windows Update process.
Basically, creates a program dashboard for change control.
Targeting January 2018 to go live<o:p></o:p></li>
</ul>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Reviewing all external facing
communications (e.g. websites, contracts) for consistency
and improvement opportunities<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">EIDAS Technical Best Practices
Document status: (submitted to Head of eGovernment and Trust
Unit for the EU) in coordination with the other Browsers
(Mozilla, Google and Apple) * Basically, a summarized
version of browser program requirements related to technical
best practices<o:p></o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l10
level1 lfo4;background:white">
Receipt acknowledged but no additional feedback or next
steps proposed<o:p></o:p></li>
</ul>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Other areas of recent focus include:
* Certificate Transparency (CT)<o:p></o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l23
level1 lfo5;background:white">
Building out CT Monitor as part of TRP<o:p></o:p></li>
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l23
level1 lfo5;background:white">
Participating in CT policy days with other browsers in
November<o:p></o:p></li>
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l23
level1 lfo5;background:white">
Impact of CT on Govt partners?<o:p></o:p></li>
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l23
level1 lfo5;background:white">
DNS Certification Authority Authorization (CAA)
Implementation<o:p></o:p>
<ul style="margin-top:0in" type="circle">
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l23
level2 lfo5;background:white">
Given that CAA is now mandatory and ballot 214 is
currently in voting period, Microsoft will give
immediate dispensation for CAs to issue certificates
following the algorithm specified in either RFC 6844 or
RFC 6844 as amended by Erratum 5065 when performing the
mandatory pre-issuance CAA checks. If Baseline
Requirements are updated to require Erratum 5065
algorithm, then CAs will be expected to transition to
this updated algorithm within a reasonable amount of
time which may be specified by a follow on ballot to 214
in the CAB Forum.<o:p></o:p></li>
</ul>
</li>
</ul>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">SHA-1 deprecation updates can be
found at </span><a href="http://aka.ms/sha1"
moz-do-not-send="true"><span
style="color:#0044AA;border:none windowtext
1.0pt;padding:0in">http://aka.ms/sha1</span></a><span
style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<b><span style="color:black">Google Root Program Update -
Devon</span></b><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Notetaker: Peter<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Google Chrome Program Update<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Devon presenting<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">- Chrome has shipped new certificate
parser on all platforms -- used instead of platform native
parser or BoringSSL (Linux on 63 is the last to land)<o:p></o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l13
level1 lfo6;background:white">
- Q: Why did Chrome do this?<o:p></o:p>
<ul style="margin-top:0in" type="circle">
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l13
level2 lfo6;background:white">
A: Foundational component for future work<o:p></o:p></li>
</ul>
</li>
</ul>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">- CT: Some churn on log list.
Expect-CT experimental header shipped in Chrome 61. Starting
to take a better look at inclusion proof checking, both in
browser and in the crawler, to help assure things are
included in the log.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">- UI: HTTP Bad is continuing to roll
out to mark as negative indicator. 62 marks as negative in
incognito mode and any use form interaction. New paper on
research.google.com on causes of TLS errors; data is being
used to create TLS error pages. New MITM page that triggers
on known misconfiguration page for AV and detected captive
portals.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">- As of yesterday, Google has signed
the CCADB agreement, so they are now officially working with
Mozilla on CCADB<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">- Symantec blog post is up; managed
PKI discussion is continuing on m.d.s.p<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">- Want to push CP/CPS to follow RFC
2527 & 3647 formats (for those not using either)<o:p></o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l16
level1 lfo7;background:white">
- Gerv comment: Mozilla wants all to move to 3647<o:p></o:p></li>
</ul>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">- Looking to improve incident
response reporting and blameless post-mortem practices and
increased transparency. Revocation is necessary but not
sufficient response in many cases.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">- Q re CT: Is April finalized? A: CT
policy days will finalized the exacts dates<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">- Q on cert parser: Does it affect
path processing? A: No. Still using securityframework on mac<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">- Q: Have they put out final details
on CT days? A: Will check with R. Hurst<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">- Q: Are you confident that the CT
ecosystem is strong enough to support April date? A: Yes, R.
Hurst's team is working to flush out any remaining bugs on
the Trillian code base<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">- Q: Will a certificate issued with
SCTs that are trustworthy at issuance continue to be
SCT-valid if the logs are later distrusted? A: Policy calls
out log trusted at time of issuance, not at time of TLS
handshake<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">- Q: Is there a single central place
that has a reference list of trusted logs? A: Yes, it is on
gstatic<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">- Q: Will logs be distrusted
retroactively? A: (Gerv) There is a possibility that it
could happen, especially for a small period of time, but
unlikely.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">- Q: Will Google work with Mozilla
on best practices to avoid conflict? A: Yes, but these are
just best practices, not specific requirements. A: (Gerv) I
doubt there will be significant disagreements<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<b><span style="color:black">Apple Root Program Update</span></b><span
style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Notetaker: Wayne<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Curt Spann -<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">- Just released iOS 11 and MacOS
High Sierra – these releases include the improved revocation
checking mechanism that was presented in Berlin<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">- Latest batch of improved root
inclusions have been completed<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">- Focusing on creating a CT log
policy. It will include a log monitoring solution. Curt will
be at CT policy days in November and is looking for
community input.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Peter – does slight false positive
risk present in the new revocation mechanism still exist?<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Geoff – Yes, nothing has changed. We
are not hearing about false positives. The IDP flag in CRLs
does cause issues with this revocation mechanism – avoid IDP
(partitioned CRLs) if possible. If having a problem with
revocation on the latest version of iOS or OS X, try:<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">• Enable OCSP Stapling (immediate)<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">• Update CRLs (take effect with next
download version)<o:p></o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l17
level1 lfo8;background:white">
• Publish a full CRL (no issuingDistributionPoint)<o:p></o:p></li>
</ul>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">• Place relevant certificates in
Certificate Transparency (weeks)<o:p></o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l0
level1 lfo9;background:white">
• For every CA, put one cert in CT which references a full
CRL<o:p></o:p></li>
</ul>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">• Contact </span><a
href="mailto:certificate-authority-program@apple.com"
moz-do-not-send="true"><span
style="color:#0044AA;border:none windowtext
1.0pt;padding:0in">certificate-authority-program@apple.com</span></a><span
style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Peter – can anything be done to
eliminate a specific false positive?<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Geoff – no, because the certificates
that trigger false positives will change over time.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Robin – it’s generally not in the
CA’s control if OCSP stapling is used or not.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Geoff – if, worst case, you can’t
get customer to implement OCSP stapling, reissue the cert.
The new serial will solve the problem for that specific
certificate.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<b><span style="color:black">WebTrust Update</span></b><span
style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Notetaker: Kirk<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Jeff Ward, Don Sheehy, and Gord Beal
made the following presentation (available for download)<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Current Status: WebTrust for CA 2.1
is complete. Generally, sections added on key migration,
destruction and transport that were not in ISO21188. V2.1
will be effective September 1, 2017. hanks to CA/B members
for comment<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Details of changes in WebTrust for
CAs v2.1 – Includes: Updated introduction section, including
clarifying definitions for Root CA, Intermediate / Issuing
CA, and Subordinate CA, and added explanation of a Bridge CA
structure.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Removed references to WebTrust v1
for Business Practices Disclosures. All CP / CPS documents
must now be in accordance with RFC 3647 (recommended) or RFC
2527.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Updated the following criteria: •
Criteria 1.1 and 1.2 –removed WebTrust v1 references •
Criteria 2.1 and 2.2 –swapped order to be consistent with
1.1 and 1.2 • Criterion 3.6 –Expanded scope to specifically
address hypervisors and network devices • Criterion 3.7
–Expanded scope to specifically address system patching and
change management activities • Criterion 3.8 –Clarified
scope to include requirement for backups of CA information
and data to be taken at regular intervals in accordance with
the CA’s disclosed business practices. • Criterion 4.5
–Split into two criterion (4.5 and 4.6), subsequent criteria
renumbered • Criterion 4.6 –Clarified scope to include
destruction of any copies of CA keys for any purpose, and
added illustrative controls addressing formal key
destruction ceremonies. • Criterion 4.10 –New criterion
added to address CA Key Transportation events • Criterion
4.11 –New criterion added to address CA Key Migration events
• Criterion 6.1 –Streamlined criteria, minor updates to
illustrative controls • Criterion 7.1 –Updated to address
cross certificate requests<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Current Status – WebTrust for
Publicly Trusted Code Signing: Modified version released to
fix error in material and to remove unauditable criterion
Removed Principle 2, Criterion 5.11 as it was determined not
to be auditable Clarified Principle 2, Criterion 3.2 with
regards to the signing of Subscriber Agreements Vs 1.01
effective October 1, 2017<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Current Status - WebTrust EV Code
Signing: Released vs 1.4.1 effective October 1, 2017 Removed
Principle 2, Criterion 5.12 as it was not auditable<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Current Status - WebTrust EV SSL:
Released vs 1.6.2 effective October 1, 2017 Updated EV SSL
Audit Criteria to conform to EV SSL Guidelines v1.6.2 and
other clarifications, including the following: • Principle
2, Criterion 2.2.3 –Updated maximum EV certificate lifetime
to 825 days • Principle 2, Criterion 3.2 –Clarified signing
requirements for Subscriber Agreements • Principle 2,
Criterion 4.13 –Codified the requirements regarding the CA’s
responsibility for verifying the accuracy of QIISs used for
verification<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Current Status - WebTrust Baseline
Requirements including Network Security Requirements
Released vs 2.3 effective TBD based on CABF feedback Updated
SSL Baseline Audit Criteria to conform to SSL Baseline
Requirements v1.4.9 and Network and Certificate System
Security Requirements v1.1 Principle 1, Criterion 6 –Require
CAs to disclose their CAA Records policy in their CPS
Principle 2, Criterion 2.14 –Clarified the requirement for
Root and Subordinate CA Subject Information Principle 2,
Criterion 4.6 –Revised age of data from 39 months to 825
days Principle 2, Criterion 4.10 and 4.11 –New criteria
added to address CAA Records processing requirements
Principle 2, Criterion 4.12 and 4.13 –Renumbered from 4.10
and 4.11 Principle 2, Criterion 8.3 –Updated that this
criterion is only effective for certificates issued before
11 August 2017 Principle 4 –Updates made to conform to CA/B
Forum Ballot 210<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Current Status –DRAFT Practitioner
Audit Report templates: Approved by AICPA / CPA Canada
Released Sept 1, 2017 Covers nearly all potential types of
reports (about 18 examples in each) and assertions Separate
documents created for each governing body (US, Canadian and
International) Needs to be followed to get the seal from CPA
Canada<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Current Status - updating/preparing
WebTrust for RAs: 2ndDraft version in process Will have main
principles similar to WebTrust and additional principles
(appendices) for Baseline Requirements including Network
Security Requirements and for EV Strength of controls will
be an issue Reporting alternatives being discussed including
SOC2 like, public report and impact on CA report<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Current Status – IN PROCESS:
Practitioner guidance for auditors Under development
covering public and private CAs. Draft expected early 2018<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Some Old and Some New Issues:
WebTrust for CA reports –should a more detailed version be
created similar to SOC 2 (limited distribution/no seal) or
report with detailed system description and controls Cloud
questions continuing to surface -perhaps WT for RA will help
lay groundwork for other delegated third parties<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">CPA Canada Now: Gord Beal, Bryan
Walker, Kaylynn Pippo (maternity leave), Lori Anastacio,
Janet Treasure. Consultant to CPA Canada: Don Sheehy (Vice
–chair) Task Force Members and Technical Support Volunteers<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Task Force Members and Technical
Support Volunteers: Jeff Ward (Chair), BDO; Daniel
Adam,Deloitte; Chris Czajczyc, Deloitte; Tim Crawford, BDO;
Reema Anand, KPMG; Zain Shabbir, KPMG; David Roque, EY;
Donoghue Clarke, EY.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Reporting Structure/Roles: Gord Beal
–WebTrust falls into Guidance and Support activities of CPA
Canada Janet Treasure –Seal system responsibility Bryan
Walker –Licensing advisor Don Sheehy -Task Force and CABF
Jeff Ward -Chair of the WebTrust Task Force and primary
contact All Task Force members provide WebTrust services to
clients Volunteers are supported by additional technical
associates and CPA Canada liaison but report to CPA Canada<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">CPA Canada activities Auditor list
updated More formalization and support in seal issuance and
licensing processes.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Questions: Gerv noted there had
recently been a question about changes in the BRs (relating
to CAA implementation) that presented technical problems,
and which might result in some CAs receiving Qualified
audits, even though they were trying to comply with all BR
and audit requirements. He observed that there may be a
benefit to the current lag time between when changes are
adopted in the BRs and when they appear in the BR WebTrust
requirments, because issues in the BRs can be fixed before
they find their way into the BR WebTrust requirements.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Others commented on this issue, and
expressed the following points of view:<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">• The BRs presently require CAs to
follow the most current version of the BRs, and to promise
they are doing so in their CPS – whether or not the changes
to the BRs are included in WebTrust for BRs. This could
create a problem. Gerv thought it might be good to remove
that requirement from the BRs and only require CAs to follow
the current BR WebTrust requirements, as those were the only
requirements that are actually tested and reported to the
browsers and public. In that way, browsers can give CAs
special and temporary dispensation to not follow certain
problematic BR changes before they are incorporated in the
next WT BR release.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">• There was discussion of whether a
CA could face an audit problem if there is a mis-match
between the BR requirements and the current BR WT
requirements. The auditors said it would depend on the level
of importance of the issue, and in some cases the auditor
might simply comment on the issue in the audit report but
the CA would not be at risk of failing the audit or even
receiving a qualification.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">• The browsers don’t want these
ballot problems to occur often, so the Forum should try to
avoid ballot problems like what occurred with Ballot 214
regarding CAA errata. Gerv pointed out that the problems
with CAA and the ballot only became obvious at a later date.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">• Jeff Ward noted there will always
be a delay in getting changes in the BRs into a new version
of the BR WebTrust requirements. Gerv noted that browser
root program requirements (including special and temporary
dispensation from BR compliance) can be done more quickly
and easily than updating the BR WebTrust requirements.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">• Wayne thought this problem could
be solved in part by new and better effective dates in the
ballots themselves<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">• Curt asked how browsers could be
assured that CAs are following the latest BR requirements if
they are not covered by the latest BR WebTrust requirements.
Gerv noted that some requirements are external, and
non-compliance can be observed by the browsers.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">• Devon noted that auditors are in
the best position to know if a CA is in compliance –
browsers generally can’t check for compliance.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">• Gerv emphasized that the
conversion of BR changes to new BR WT requirements is a
process (including determining what in the BRs is
auditable), and so can’t always be speeded up.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">• Don noted that when the EV
requirements were created, the Forum went created a long
list of Errata to correct the early versions of the EV
requirements, and the WebTrust auditors were not required to
change the audit requirements on a weekly or monthly basis –
the audit criteria were more stable then, which was better.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">• Kirk said if Gerv had ideas on
changes to make to the BRs to deal with these issues, he
should propose them Gerv said he would move forward with
suggestions.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<b><span style="color:black">ETSI Update</span></b><span
style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<a
href="https://portal.etsi.org/TBSiteMap/ESI/ESIActivities.aspx"
moz-do-not-send="true"><b><span
style="color:#0044AA;border:none windowtext
1.0pt;padding:0in">https://portal.etsi.org/TBSiteMap/ESI/ESIActivities.aspx</span></b></a><span
style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Notetaker: Enrico<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Arno presented an Update on the ETSI
Working Group ESI: (Electronic Signatures and
Infrastructures)<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">ISO 17065 is one of the foundations
of the ETSI Certification Policies based audit scheme.
Caused by the eIDAS Regulation an European accreditation
system is incorporated into the audit scheme. There has been
the need over the past few years for a better way to know
who is accredited as an auditor for ETSI CP, because ETSI is
an official standardization organization that does not
oversee audits.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">The accreditation scheme is not
person-based, it is accreditation of the auditing body – the
Conformity Assessment Body (CAB). The CAB is responsible for
the quality and skills of the auditor and the quality of
their work. In Europe, at the top level, there is the
European Accreditation Authority (</span><a
href="http://www.european-accreditation.org/"
moz-do-not-send="true"><span
style="color:#0044AA;border:none windowtext
1.0pt;padding:0in">http://www.european-accreditation.org</span></a><span
style="color:black">). A CAB must conform to the ISO 17065
and must be accredited to audit pursuant to ETSI 319 403. To
verify whether the CAB is accredited, you can request its
accreditation certificate, and the certificate will need to
reference the applicable standards for which the CAB is
accredited. The ACAB’C is now an organization that cares
about the quality of the auditor. ETSI has created a
detailed audit check list for auditors who audit CAs, the
check list includes more than 300 specific controls.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Standards are available for download
at </span><a href="http://www.etsi.org/standards-search"
moz-do-not-send="true"><span
style="color:#0044AA;border:none windowtext
1.0pt;padding:0in">http://www.etsi.org/standards-search</span></a><span
style="color:black">. The most important standard for this
group is EN 319 411-1 . End of October 2017 an actual
version will be published.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<b><span style="color:black">Governance Working Group Report</span></b><span
style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Notetaker: Ben<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">During the Policy Review Working
Group meeting we went over a proposed change to the
definition of Certification Authority. It would be amended
to read, “a technical certificate generation service that is
trusted by one or more entities to create and revoke or hold
public key certificates and is operated by a Trust Service
Provider.” And after that discussion, we received a comment
from GDCA that they would like it to refer to a “logical
entity”. GDCA was going to post something to the list to
clarify this request. GDCA clarified that the request was so
that the definition of a CA was not limited to a service, so
that it could be an organization. Ben said that the
“organization” part is under the last part of the definition
that mentions “Trust Service Provider” and that he had
misunderstood GDCA’s request. Ben said that we could say “a
logical entity or service”, or we could leave the definition
as proposed. Ben noted that the definition was a combination
of ETSI and ISO definitions crafted by Peter Bowen. Peter
said he didn’t mind having “logical” in the definition if it
would help non-native-English speakers. It was agreed that
further discussion on the public email list would be of
benefit to everyone on this issue. Dimitris said that he had
the definition in an email from September 14 that could be
referenced, and Ben said that he had forwarded that email to
GDCA. Kirk suggested that they provide examples of the
logical relationship to make it clearer for people to
understand what is being proposed.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Another topic discussed was a review
of the Baseline Requirements and the use of the word “CA” to
determine whether we’re talking about the organization or
the logical entity / service that signs and revokes
certificates. The relative frequency of places where “CA”
will remain is high when compared to places where we would
replace CA with Trust Service Provider.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Dimitris noted that during the
discussion on Tuesday we also focused on “trusted by one or
more entities” in the proposed definition and whether it
should say “trusted by Application Software Suppliers.” Ben
said that you could word it by leaving that phrase out and
saying “trusted to create and revoke” or “trusted by
subscribers and relying parties” because Application
Software Suppliers are acting as agents for relying parties.
Dimitris said he is fine with the definition as is. Ben
noted that the next speaker had joined and that we should
take the topic offline and continue it during the next call
or on the mailing list.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Finally, Ben noted that in reviewing
the use of the term “CA” he identified an inconsistency
between the Baseline Requirements and the EV Guidelines. In
the Baseline Requirements section 7.1.6.3 we talk about use
of the anyPolicy policy OID by an “affiliate of the Issuing
CA” whereas in section 9.3.4 of the EV Guidelines we say it
may be used for a subCA “for which the corresponding Private
Key is controlled by the Root CA.” Ben said he prefers the
usage found in the EV Guidelines. It was suggested that with
the modified definition of CA, section 9.3.4 of the EV
Guidelines could even be edited to read, “(2) Certificates
issued to Subordinate CAs that are operated by the same
Trust Service Provider as the Issuing CA MAY contain the
special anyPolicy identifier (OID: 2.5.29.32.0).”<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<b><span style="color:black">CCADB Update and demonstration</span></b><span
style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Notetaker: Mike Reilly<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">• Purpose: Common CA Database
(CCADB) Demo was presented as a result of CA feedback and
questions on use of the database.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">• Demo started with an overview of
the “Information for CA” page. Aaron walked through the
process of creating a new audit case and how it’s tracked in
the dashboard. New audit cases are based on CA information.
Currently a manual process is used to validate this
information, but validation will become automated soon as
part of the Jixi project mentioned in the Microsoft update<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">• Question asked: Will the CCADB
replace Bugzilla? No, currently Bugzilla pulls reports from
CCADB to provide info to CAs and others. Microsoft, Mozilla
and Google use this CCADB (Google just announced they are
joining it) to track CA information in support of their root
programs. Apple is looking to use it as well and is going
through legal review to start using it.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">• Auditors would like to see the
CCADB data as well. Follow up: Kathleen to discuss with
Microsoft and Google to see how we may do that.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">• A new field has been added that
shows auditor information and allows for easy add of auditor
from a drop-down list<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">• Audit statement (PDF) is added and
audit type is selected along with audit date. Audit date
cannot be more than 90 days past the end date. If a CA has a
reasonable reason why they went past 90 days they can add
comments<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">• Question asked: can the file name
for audit document URL be the same each year? No, since we
require new filenames/URLs for audit statement each year,
please have CAs to use a new filename for a new document<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">• CAs should list all certs in the
CCADB that way browsers can cross reference and the CA has
less data input requirement overall to get info to browsers
using CCADB<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">• Question asked: One CA had to
upload the same audit document multiple times for multiple
roots and wondered if there was an easier method. Answer was
that CA still need to create multiple roots under one Audit
Case if audit document is the same one, and CA can create
multiple audit cases for different audit statements.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">• Positive comments by a few folks
as to the good design and ease of use for adding audit
documents<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">• Are the dashboard tools available
to the CAs? (EKU Management, Audit Standards, etc view).
Those views are part of the “Jixi” project Microsoft
mentioned in its update and will be demonstrated at the
March f2f CABF meeting. Mike to take action to update CAs on
what views and reports Jixi will provide for their use<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">• Question: Any plans for adding
submission APIs so it’s easier for CAs to add their
information? Answer is NO, so far CA still need to create
each case/root case one by one, no API supported for now.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">• Question: Will “bulk load”
capability be available? CA would need to get in touch with
Kathleen if this is needed. It was used initially to get all
CAs onboarded<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">• There are also detailed
instructions on the CCADB site should CAs want to follow up
on how to use the CCADB (Gerv comment)<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<b><span style="color:black">Guest Speaker: Jonathan Levi -
Hyperledger Fabric Project 1.0 update and usage of x.509
v3 certificates</span></b><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<b><span style="color:black">Approve Minutes CABF
teleconference Sept. 14, 2017</span></b><span
style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">The Minutes were approved, and will
be posted to the Public list.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<b><span style="color:black">Determine Applicability of
Certificates by using standard CABF CP OIDs</span></b><span
style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Notetaker: Li-Chun Chen<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Dr. Wen-Cheng Wang changed his
presentation title from original "Using CP OIDs instead of
Extended Key Usage to distinguish different kinds of
Certificates" in meeting agenda to "Determine Applicability
of Certificates by using standard CABF CP OIDs" </span><a
href="https://www.cabforum.org/wiki/Meeting%2042%20Minutes?action=AttachFile&do=view&target=Determine+Applicability+of+Certificates+by+using+standard+CP+OID.pdf"
moz-do-not-send="true"><span
style="color:#0044AA;border:none windowtext
1.0pt;padding:0in">Determine Applicability of Certificates
by using standard CP OID.pdf</span></a><span
style="color:black">.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">At first Wen-Cheng asked the
audience that: When a certificate-using software (such as a
browser) encounter a SSL certificate or a code-signing
certificate that is chained up to a trusted Root CA, how
does it determine whether the certificate is issued by a
Subordinate CA that conforms the applicable CA/Browser Forum
guidelines?<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">He said: Currently, there is no
systematic and automatic way to check this applicability.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">In the slide page 3 about
Mis-issuance by Unconstrained CA, The PKI is </span><a
href="https://www.cabforum.org/wiki/WebTrust"
moz-do-not-send="true"><span
style="color:#666666;border:none windowtext
1.0pt;padding:0in">WebTrust</span></a><span
style="color:black"> for CA Audited. SubCA 1 is </span><a
href="https://www.cabforum.org/wiki/WebTrust"
moz-do-not-send="true"><span
style="color:#666666;border:none windowtext
1.0pt;padding:0in">WebTrust</span></a><span
style="color:black"> SSL BR audited. So SubCA1 can issue
OV/IV SSL Certificates. SubCA2 is </span><a
href="https://www.cabforum.org/wiki/WebTrust"
moz-do-not-send="true"><span
style="color:#666666;border:none windowtext
1.0pt;padding:0in">WebTrust</span></a><span
style="color:black"> EVCS audited. So SubCA2 can issue EV
Code Signing Cert. SubCA3 is not “</span><a
href="https://www.cabforum.org/wiki/WebTrust"
moz-do-not-send="true"><span
style="color:#666666;border:none windowtext
1.0pt;padding:0in">WebTrust</span></a><span
style="color:black"> SSLBR” audited or “</span><a
href="https://www.cabforum.org/wiki/WebTrust"
moz-do-not-send="true"><span
style="color:#666666;border:none windowtext
1.0pt;padding:0in">WebTrust</span></a><span
style="color:black"> EVCS” audited. SubCA3 could mis-issuse
SSL certificates or EV Code Signing certificates unless all
SubCAs are “Technically Constrained”. In the slide page 4,
Wen-Cheng discussed some application software use EKU
Chaining in Sub CA certificates and EE Certificates to let
SubCAs to be "Technically Constrained".<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Using EKU in Sub CA certificate is
controversial. The section 4.2.1.12 of RFC 5280 says “In
general, this extension will appear only in end entity
certificates.” Both ITU-T X.509 and RFC 5280 say nothing
about the semantics if this extension appeared in CA
certificates.The is no EKU Chaining (a.k.a. EKU nesting) in
the standard certification path validation procedure define
in both ITU-T X.509 and RFC 5280.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Wen-Cheng reminds that the X.509
standard and RFC 3647 define a Certificate Policy (CP) as "A
named set of rules that indicate the applicability of a
certificate to a particular community and/or class of
application with common security requirements." For example,
a particular certificate policy might indicate the
applicability of a type of certificate to the authentication
of electronic data interchange transactions for the trading
of goods within a given price range. A CP is represented in
a certificate by a unique number called an "Object
Identifier" (OID). When a CA places multiple CPs within a
certificate's Certificate Policies extension, the CA is
asserting that the certificate is appropriate for use in
accordance with any of the listed CPs. CA/Browser Forum had
defined several CP OID as below.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">EV SSL CP OID: 2.23.140.1.1<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">EV Code Signing CP OID: 2.23.140.1.3<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">DV SSL CP OID: 2.23.140.1.2.1<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">OV SSL CP OID: 2.23.140.1.2.2<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">IV SSL CP OID: 2.23.140.1.2.3<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Each CP OID indicates the
applicability of different type of certificate.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">From the perspective of audit,
Wen-Cheng in his slide page 8 shows the Audit Applicability
Matrix quoted from </span><a
href="http://www.webtrust.org/principles-and-criteria/docs/item83986.xlsx"
moz-do-not-send="true"><span
style="color:#0044AA;border:none windowtext
1.0pt;padding:0in">WebTrust for Certification Authorities
- Audit Applicability Matrix</span></a><span
style="color:black"> in <a
href="https://www.cabforum.org/wiki/WebTurst"
moz-do-not-send="true"><span
style="color:#666666;border:none windowtext
1.0pt;padding:0in">WebTurst</span></a>website. “CABF BR
+ CABF Network and Certificate System Security Requirements”
define a set of rules (i.e. effectively a CP) for the
applicability of publicly-trusted DV, OV, or IV SSL
certificates.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Wen-Cheng said “CP OID Chaining” is
well-defined in the certification path processing procedure
of the X.509 standard and RFC 5280. Where<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">user-initial-policy-set: comprising
one or more certificate policy identifiers, indicating that
any one of these policies would be acceptable to the relying
party for the purposes of certification path processing.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">initial-explicit-policy = true:
indicates an acceptable policy identifier needs to
explicitly appear in the certificate policies extension
field of all public-key certificates in the path.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Processing intermediate
certificates: each CP OID that appears in an intermediate
certificates must also appear in the upper-level
intermediate certificate or in the user-initial-policy-set.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Each CP OID that appears in the
end-entity certificate must also appear in the intermediate
certificates.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">In page 16 of Wen-Cheng's slide, he
showed a table from </span><a
href="https://cabforum.org/object-registry/"
moz-do-not-send="true"><span
style="color:#0044AA;border:none windowtext
1.0pt;padding:0in">https://cabforum.org/object-registry/</span></a><span
style="color:black"> about CABF compliance OID. Most of the
CAs put their private CP OIDs in their intermediate CA
certificates and EE Certificates. What should we do?
Wen-Chung suggested to enforce to adopt CABF CP OIDs. Set a
sunrise date as below:<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Effective DD MM YYYY, CAs MUST use
the following CP OIDs in the subordinate CA certificates and
the subscriber certificates. Maybe two years later.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Note that currently </span><a
href="https://technet.microsoft.com/zh-tw/library/cc751157.aspx"
moz-do-not-send="true"><span
style="color:#0044AA;border:none windowtext
1.0pt;padding:0in">“Microsoft Root Certificate Program”</span></a><span
style="color:black"> already mandate the use of CABF CP
OIDs 4.15 CAs must use the following OIDs in the end-entity
certificate: DV 2.23.140.1.2.1; OV 2.23.140.1.2.2; EV
2.23.140.1.1.; IV 2.23.140.1.2.3; EV Code Signing
2.23.140.1.3; Non-EV Code Signing 2.23.140.1.4.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">For Browsers, All of the Root CA
certificates in the trust list must associate with one or
more applicable CABF CP OIDs.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Wen-Cheng concluded that the
advantages of determining the applicability of certificates
by using standard CABF CP OIDs instead of EKUs is that it
can provide a uniform, systematic, and automatic way to
determine the applicability of different types of
certificates. It is fully compliant to the certification
path processing procedure defined in the X.509 standard and
RFC 5280.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Let’s do the right thing in a way
that we do it right<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Do the right thing: we must always
check the applicability of certificates<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Do it right: By enforcing standard
CABF CP OIDs, we can systematically check applicability of
certificates.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Ans: If people wants to use their
own private PKI, they have to import their own Root CA to
browser. They can assign appropriate CP OIDs in their
certificates, so we can still use the systematical way to do
the CP OID validation.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Ans: So if the appropriate CP OIDs
are assigned, the browser can knows that it is OV or EV on
path processing.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Q: The browser wants to check if the
certificate is mis-issued according to CAB’s baseline
requirement. If a CA wants to mis-issue certificate, it can
easily add the CP OIDs into the mis- issued certificate.
Your opinion is asking all browsers to change the software
to check the CP OIDs and all CAs must add CP OIDs into
intermediates to achieve something that is not much valued.
That is my concern to this proposal and I don’t think it
will work.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Ans: The CA should disclose the CP
OIDs used in their certificates, so it could be easily
determine the certificate has appropriate CP OIDs or not.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Q: The Web PKI doesn’t do CP OIDs
checking.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Ans: It depends on browsers. I know
Firefox and NSS don’t process certificate policies.
Microsoft requires all CAs to have appropriate CP OIDs end
entities, since these CP OIDs may not in intermediates.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Q:Your opinion is to request browser
to full process the CP OIDs in path building. These is not
only to end entities, since Microsoft require all the root
certificate has these CP OIDs too.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Ans: I think it is a big challenge
to trust stores and browsers, but in long term it is a right
way to do it.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Q: What is the problem that we are
trying to solve? You are trying to use a trusted root to
issues certificates to intermediates that not comply with
baseline requirements.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Q: If the browser claim requires
CT/SCT is embedded in the certificate, it also works and in
such CA, any issue among in OV and EV situation, roughly in
24 hours condition, is that correct?<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Ans: Yes. If someone find there’s
something wrong and he commits and reports to the browser of
course you can stop the CA. But you already accepted, by
using the CP OIDs, you will reject this kind of certificate
immediately.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Q: Yes. Right now we are in reactive
position. We will detect them. Something prevents it. You
mention we need 24 hours to solve them but in situation, no
one saw them and the browser will reject certificate there
for about a process time.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Ans: If someone find there’s
something wrong in the middle, some CA issue website
certificate and is not issued by me. I will get some report
to the browser. Browser will ask CA to fix. So mis-issued
problems happen from time to time. So if we can have a
systematical way, we can reject this kind of mis-issued
certificate immediately<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Q: You want the ability to have a
root CA that essentially issues a constraint supported to a
3rd party that has different controls to the root CA. So you
don’t completely trust, you want to be able to issue to
something else, the supported CA, cross sign, and
explosively exclude them. Say I know I sign that, I
disclaiming responsibility in the mis-issue. Is that right?<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Ans: Of course the CA has the
liability to perform well management of their system, but
here I just like to comment this is a standard when check
the certificate. And in this way if there is an issue, it
can be automatically rejected.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Q:If you have a RootCA issuing the
SubCA then they have to be concern about their compliance
with the baseline requirements. If you can somehow do that
with some other mechanisms such as like CP OID rather than
EKU then you can do that maybe this is also a build
suspenders part of that. What the idea is that maybe you can
control your reliability by doing that and not be such as
oids of subCA what you created if it’s like an external
subCA.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Ans: What I would like to suggest
putting this CP OID checking is that it can help browser to
automatically detect the mis-issued of these certificates.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Q:It’s not evil bit said and you are
saying this is a mis-issuance but what said be not evil bit
but I am saying the mis-issuance they can be mis-issuing and
then they can just issue said to be not evil bit. In which
case, you know, We will assume, it’s not evil, they will
check they are not evil bit. Actually it is not evil.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Ans:I do not invent this. This is
defined in the standard. We commend we use this checking
standard. The advantage using this kind of OID checking is
because that it is systematical and automatic.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Q: Is there a need to do this
change? What is the problem you try to resolve?<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Ans1: Different CA has different
hierarchy, for example, If an RCA only has one subCA, then
EKU chaining is enough.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Ans2: EKU chaining is simple. But
there might be non-browser applications processing ICA
certificate with EKU will have problems.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Ans3: CP OID Chaining is a
systematic and automatic way to detect miss-issued
certificates. It lets browsers and other clients to detect
and block miss-issued certificate immediately rather than
reported later by other parties.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Q: There are many different
implementations among Browsers and CAs, so it is challenging
to do this change.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Ans: We know it is challenging, but
we just want to evaluate the possibilities of this change.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Q: The Key issue is the EKU
Extension should not be used for certificate signing. If the
EKU extension is non-critical, will it prevent the
standard-violation problem?<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Ans: As far as we know, If you
recognized the EKU Extension, you should process it no
matter it is critical or not.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Ans: Critical or non-critical. The
standard says that if certificate use the software which
recognizes EKU, you need to process it, even the EKU
extension is marked as non-critical<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Ans: Yes, service can process and
understand. In case Microsoft certificate services, if you
could put EKU into supported CA, that means sub-CA can issue
any client certificates that have different OIDs, not
including any EKU extension of sub-CA.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Ans: That’s what I emphasize then.
How we replace EKU with CP OID. I suggest all of CAs add the
standard of CA/Brower Forum OID into certificate. This is
first step you need to do. If all of intermediate CA and
subscriber certificates contain these standard CP OIDs, then
the certificate using system, such as browser or the
operating system or even the future software can check these
CP OIDs chain automatically. Prevent the accident of
mis-issue immediately.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Q: Right, this means that get back
to the point, say EKU constrained is?<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Q2: Right, I think the general
answer is so? That’s what we’re using paper works. Everybody
signs up to it, and everybody is using it. It does its job.
It’s great deal and let’s it!<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Ans: There is an improvement because
you can automatically detect.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Q: You can use EKU chain. EKU desti
and you can all of this, right?<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Ans: Yeah! You can also use the EKU
to do this check. But the problem is controversial and also
caused other problem. The certificate is varied by other
standard complies, such as the C and the CPP software. It
might be affected if you use the EKU chain.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Q: The Web PKI is the web PKI.
Sometimes that’s the way it is.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Ans: Currently, In the BR also faces
that in general the EKU do not in the subordinate CA group.
But, currently we use in the subordinate group.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Q: It’s optional extension.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Q2: So do we turn into the
discussion or are there more and more to discuss?<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Ans: Just want to ask Browsers. Do
you want to implement this and the mechanism? In the long
term, I say this is the right way issue. I do not suggest we
immediately implement this. I don’t know how long we need
take to implement this, and how long the standard CP OIDs
will be in or on the subordinate CA. But we are gathered
here to improve the trustworthiness of the certificate. I
think in the long term we should have the systematic way and
automatically way to detect this issue. This is why I want
to propose.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<b><span style="color:black">Validation Working Group Report</span></b><span
style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Notetaker: Jeremy<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">1. Backlog ballots<o:p></o:p></span></p>
<ol style="margin-top:0in" start="1" type="a">
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l21
level1 lfo10;background:white">
Non-latin qualified notaries b. SRVNames c. ASN.1 for JOI<o:p></o:p></li>
</ol>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">2. Ballot 190 Experiences<o:p></o:p></span></p>
<ol style="margin-top:0in" start="1" type="a">
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l11
level1 lfo11;background:white">
Everyone generally agreed that the documentation/revision
storage was fairly difficult. Most are storing the
information as a date that correlates to a BR version b.
Jeremy said there’s a lot of inconsistency in the language
that we need to fix c. Tim said the random value means two
different things – sometimes it means a nonce and sometimes
it is a secret. Redefining the term will clarify the
confusion d. The language sometimes refers to an unknown
actor. The room agreed generally that the CA should be the
actor in all cases. This requires clarification e. Jeremy
said there’s confusion about whether items can be used
cross-method. Tim said this is clarified once we fix the
nonce/secret confusion f. Document/information reuse is
confusing. g. The scope of the domain approval is also
confusing. Sometimes the document says FQDN, other times it
says authorization domain. Once it says base domain h. The
document is also unclear on the scope of the approval. How
does a subscriber know they are approving sub domains. Gerv
asked if we should require scope approval during the
verification. Jeremy thought this was a good idea.<o:p></o:p></li>
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l11
level1 lfo11;background:white">
Resuability is unclear. Each method should state what can be
reused and what needs to be redone. Each method should also
state what how long specific actions are good for.<o:p></o:p></li>
</ol>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">3. Ballot 190 Issues<o:p></o:p></span></p>
<ol style="margin-top:0in" start="1" type="a">
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l7
level1 lfo12;background:white">
Jeremy showed the issues list b. The validation WG will go
through the list on their call<o:p></o:p></li>
</ol>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">4. IP Address validation<o:p></o:p></span></p>
<ol style="margin-top:0in" start="1" type="a">
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l6
level1 lfo13;background:white">
The last proposal was circulated on March 24th b. The ballot
eliminates the “any other method” c. Jeremy recirculated the
proposal for discussion on the mailing list<o:p></o:p></li>
</ol>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">5. CAA Experiences<o:p></o:p></span></p>
<ol style="margin-top:0in" start="1" type="a">
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l12
level1 lfo14;background:white">
The biggest question was about how systems should behave if
DNS doesn’t answer. This was partly discussed on the mailing
list. There are two options. First, if there is no record,
assume the record is permissive for the CA. Second, if there
is no record keep working the chain. The first is the
correct interpretation but CAs are permitted to be more
restrictive. b. Others felt CAA was not mature enough for
adoption. The RFC needed more clarification before we tried
to implement. c. Peter brought up that DNSSEC
implementations lacked quality. CAs are required to fail
open if DNSSEC is not present, but fail close if DNSSEC is
present. d. There are issues with split horizon e. Some
failures are caused by CNAME loops f. People have seen
issues with malformed records. CAA needs better
implementation tools as these are generally caused by manual
input processes. g. Lesson learned – these new ideas need a
more phased-in approach.<o:p></o:p></li>
</ol>
<p class="MsoNormal"
style="mso-margin-top-alt:0in;margin-right:0in;margin-bottom:11.0pt;margin-left:.5in;line-height:normal;background:white"><span
style="color:black">h. There was a lengthy discussion about
CAA and the audit, especially as it pertains to the errata.
What happens now that the browser and audit requirements
differ? Ultimately, this became a non-issue as neither
WebTrust nor ETSI would updated before the errata
requirement went into effect.<o:p></o:p></span></p>
<ol style="margin-top:0in" start="2" type="a">
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l12
level1 lfo14;background:white">
The validation WG said they would write a normalization
document. j. CAA for IP Addresses is an IETF issue, not
something to discuss in the WG k. CAA flags. Four were
suggested: Validation methods, account identifier,
certificate types, and brands l. There’s a question whether
the WG will cover these or a new CAA WG will create them<o:p></o:p></li>
</ol>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">6. Root and Intermediate
Requirements<o:p></o:p></span></p>
<ol style="margin-top:0in" start="1" type="a">
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l2
level1 lfo15;background:white">
We discussed modifying 7.1.4.3.1(b). Right now it specifies
that the Sub CA must be listed in the O field. There’s a
question whether vanity issuing CAs are permitted.<o:p></o:p></li>
</ol>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<b><span style="color:black">Domain Validation Implementation
Issues</span></b><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Notetaker: Jeremy<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">See Validation Working Group Report.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<b><span style="color:black">Network Security Working Group
Report</span></b><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Notetaker: Ben<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Ben explained the background of the
Network Security Working Group. The CA/Browser Forum’s
interest in network security dates back to the Diginotar
event in 2011. As a result of Diginotar, the Forum adopted
the Network and Certificate System Security Requirements
(NCSSRs). Until recently we hadn’t revisited the NCSSRs, so
this Working Group was formed to take a look at the NCSSRs
and decide whether the repeal them and adopt some other
network security standard or edit the NCSSRs. If we had
repealed them, there are still several provisions in the
Baseline Requirements that talk about things like risk
assessment and network security, as do the WebTrust
criteria. However, the reason we originally adopted the
NCSSRs was because there was a feeling that the Diginotar
event happened because there were gaps in certain areas,
e.g., WebTrust 2.0 has Illustrative Controls, which are not
mandatory. Also, CAs have experienced pain points in
applying the NCSSRs due to different interpretations by
auditors, etc. The Working Group has gathered comments on
these and recently tackled some of the easier ones to
address in Ballot 210. We prioritized the remaining issues,
and we reviewed those during our working group meeting the
day before yesterday.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">During our working group session, we
discussed the path forward. The </span><a
href="https://www.cabforum.org/wiki/NetSec"
moz-do-not-send="true"><span
style="color:#0044AA;border:none windowtext
1.0pt;padding:0in">NetSec</span></a><span
style="color:black"> Working Group also has a subgroup
working on CA architecture, the threat model, threat
analysis, risk assessment, (i.e. what are we trying to
protect). The reason for this is that this analysis will
allow us to define security perimeters of things like root
CAs and certificate issuing systems. Meanwhile, the Working
Group will continue to discuss the remaining items on the
prioritized list. We may re-prioritize the list based on a
suggestion that we take low-hanging fruit – items that are
easier to address.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<b><span style="color:black">CAA Implementation Issues</span></b><span
style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Notetaker: Robin<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Jeremy initiated the discussion on
the topic.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">There were a number of Issues
expressed at the working group yesterday::<o:p></o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l8
level1 lfo16;background:white">
There is a lack of clarity on how the system should behave
if the DNS doesn't answer.<o:p></o:p></li>
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l8
level1 lfo16;background:white">
A lack of quality around DNSSEC implementations<o:p></o:p></li>
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l8
level1 lfo16;background:white">
RFC not mature enough.<o:p></o:p></li>
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l8
level1 lfo16;background:white">
Split horizon issues<o:p></o:p></li>
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l8
level1 lfo16;background:white">
Failures because of CNAME loops<o:p></o:p></li>
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l8
level1 lfo16;background:white">
Malformed records. Tried for CAA, but failed..<o:p></o:p></li>
</ul>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Lesson: we need a more phased
approach. Do we need a report-only mode?<br>
What happens now that BRs requirement is diffferent from
browser requirements (due to RFC errata)? This turns out to
be a non-issue, because its not yet in the audit criteria.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Kirk: - Malformed records?<br>
Jeremy - CAA missing issuernames, or nonsensical data in an
issuername.<br>
Wayne - I see a need for a toolset for people creating CAA
DNS records.<br>
There should be a way to make it much simpler for customers.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Kirk: What is still pending in CAA?<br>
Jeremy - There is still an errata which is not yet held for
update.<br>
An RFC through the ACME group with FLAGS. Errata still come.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Tim - Doug's recent thread on what
to do around retries. <br>
Jeremy: I was surprised to see the variation in expectation.
Do you fail closed or fail open?<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Wayne - what we're asking is, does
an individual DNS lookup failure count as a failure? Or do
you need to try every step?<br>
Geoff: If the server failed, you try the server and then
retry. What do you assume, if you can't get the record?<o:p></o:p></span></p>
<ol style="margin-top:0in" start="1" type="a">
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l4
level1 lfo17;background:white">
Assume no record - so you can issue.<o:p></o:p></li>
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l4
level1 lfo17;background:white">
Assume there is a record that allows you to issue.<o:p></o:p></li>
</ol>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">So for the moment a failure means
you can issue.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Gerv: That surprises me because I
would expect it to fail closed.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Geoff: I agree that it should fail
closed, but the BRs don't say that.<br>
Alex: Agree. It is bad security practice to fail open.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">PZB: Fail open if you have an
affirmative 'this isn't DNSSEC signed' indicator. Fail
closed if DNSSEC in use.<br>
Wayne: Do you have to use DNSSEC only or can you just do
DNS?<br>
....<br>
PZB: - so we're back to yesterday, the standard is OK, but
the DNS implementations suck.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Wayne - we need to get to a point
where we agree on the requirement, in this room at least.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Gerv: Agreed. A test suite would be
good - but need not be a product of the forum. A document
with use cases and expectations for edge cases.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Gerv: It is not a good use of CA's
time to work out all the edge cases. Let's do it in the
forum instead, or elsewhere, once.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">PZB: Bullet 3 is the core thing. If
you've pointed it at a private DNS server then it won't
resolve. supersecret.project.com points to 10.2.3.4. .com
zone says whether project.com is DNSSEC signed.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Steve: Assuming that you have a
DNSSEC capable system.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">CAA is discussed in the validation
WG, currently.<br>
Kirk: There may be a larger group that wants to talk about
it. (working towards the test set)<br>
Tim: start a new group<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Kirk: Can someone come up with the
charter.<br>
Geoff: I will come up with some language for a charter.<br>
Tim: Issus in implementing RFC6844 and errata in compliance
with the BRs.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">PZB: Issues and experience in
implementing 6844 and errata.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Wayne: I wanted to clarify the
ballot around 214 . Is there still an issue on how DNAMES
should be handled.<br>
Tim: Yes. That is the errata that is not yet held for
update.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Kirk: Should we get involved in the
IETF process?<br>
PZB: There is no approval process for errata. Once it has a
number (RFC6844) it never changes. Somethimes there is
enough interest to get an update - in which case it gets a
whole new number. E.g. 3280 became 5280.<br>
Jeremy: You can have a bis.<br>
PZB - that is a draft. It gets a new number.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<b><span style="color:black">CT Implementation Issues</span></b><span
style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Notetaker: Giichi<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Kirk: I’m concerned about
availability and reliability of CT log especially if this is
mandatory process for service availability for CAs. Google
seems to be confident about the availability.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Devon: what is 99% up time CT team
is primary working on getting code ready and not for
availability. The intent was to first release and monitor
traffic and uptime, etc.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Need to have clear SLA to be able to
monitor the real availability. Currently Google being the
sole determinator of up time, what it means to be. Could be
network issues. Kirk: Why trust CT log when only 98%
availability is maintained. Feels like punishing user.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Devon: heart of uptime argument is
ensuring the log doesn’t intentionally shut down
issuance There will be significant policy change to address
uptime issue. Clearly articulating the concerns around
uptime is going to affect how policy would be formed.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Gerv: are you saying there are
certificates being kicked out without notification period?<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Jeremy: during the qualification
period do we require certificate for those who do not permit
logging<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Devon: 90 days window is a
monitoring period and for people to know what’s going to be
after the monitoring period is over.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Peter: getting CT back doesn’t mean
there is a log, it’s a promise signed by a server that there
is a log. For malicious log, it issues bunch of promises, if
it’s unavailable, it take the fetch log operationally
offline then issue promises that never knows, and is never
detectable until it comes back online.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Jeremy: one of the implication we
had was that policy is not the amount of information you get
as a CA. it’s helpful to get more information from log
operator on how policy is embedded in the log.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Devon: now, there’s a clause to
catch all of this to what is public interest to find out
what is not defined what are criteria on accepting. What is
the terms for CA for acceptance? One of the non-technical
checks on whether log could be trusted. We need to address
things like what if policy changes, to some extent it’s
operated by trust store and everything need to be qualified
but based on increased feedback.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Jeremy: Would it worth coming up
with log policy?<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Devon: would be valuable. Policy on
what log operator support on CA, we would be interested to
know more about what they are doing.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Jeremy: the interest is probably
more on browser rather than public.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Devon: Browsers are the ones who
makes distrust decision based on the policy, so we want to
make sure we understand the expectations from CAs.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Kirk: I’d like to re-open the
conversation on enterprise customer don’t want to put CT and
don’t want to go back to private. Could Google explain why
name redaction cannot be done?<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Devon: long standing discussion on
this topic and could further be discussed at CT meeting.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Kirk: want to know “why” cannot<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Peter: There were several options
Ryan agreed to implement to allow enterprise to push policy
to say “for my enterprise, I do not require CT on subset of
certificates”.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Kirk; That’s not the same. They
wanted to work within their environment without having to
get warning. They don’t want to configure special setting in
order to avoid browser warning. Coming back to the original
point, what is the reason why redaction is not allowed?<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Peter: With redaction how do you
determine if one is permissible redaction or not? For
example, if Amazon decides payment.amazon.com doesn’t want
to be checked by Google? How do we ensure that doesn’t
happen?<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Kirk: That is not really a relevant
threat. If domain is validated, and it is their domain. For
payment.amazon.com, it’s Amazon who has ordered such
certificate, and they can simply ask for redaction.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Peter: Reason for CT is to avoid the
challenge of somebody misdoing it. Mozilla currently
surveillances 64 trust service providers, and the reality is
there are vulnerabilities in the process. That’s where CT
can make it easier to spot these mistakes.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Kirk: If you see payment.amazon.com
certificate and if we look at CT log, we will automatically
know or do we need to do some research?<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Peter: For Amazon certificate, every
single certificate issued from Amazon goes through internal
management system that talks to CAs and anything shows up to
CT log that aren’t in there is a major security alert.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Kirk: Yes, but that can also be done
with redaction as well.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Peter: Yes, but what do I do?<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Kirk: You contact the CA and request
for revocation. But what do you do anyway when you see a
certificate in CT and un-redacted CT that you think is not
adequate. It would be the same process, asking the issuing
CA to revoke the certificate.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Peter: We will need to investigate.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Kirk: that issue was different my
point was subscriber should be able to identify the
certificates that they don’t recognize and ask issuing CA to
revoked.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Peter: if it is redacted, all the
information subscriber get was it was issued to
xxxx.amazon.com and its serial number. Then subscriber will
need to ask issuing CA for further detail.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Kirk: that is Amazon’s specific case
of handling it. If someone finds out about certificates that
they are not sure about, they will have to research it
anyway.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Peter: what is the goal of
redaction? Under what circumstances does CA need to disclose
further information?<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Kirk: If they can prove domain
control.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Peter: What happens to redaction if
someone sells the domain?<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Kirk: that’s the use case we never
thought about.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Kirk: CAs can bring redaction issues
propose to create rules around it including points on how CA
should handle the request from subscriber.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Devon: We can probably bring
proposal and have informed discussion at CT Policy Day.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Robin: current RFC does not mention
about redaction.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Kirk: We can fix it in version 2,
but in the meantime, errata can be released.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Peter: part of issue is that
technical specification is not really finished.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Jeremy: it was abandoned because
there was no ambiguity.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Peter: RFC6962 continued to move
forward, existing methods at least needs to be updated.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Devon: another reasons for holding
up the changes to RFC6962 are that there area other
signification technical changes are coming.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Kirk: Main point is to come back
with errata and technical scheme on how to do name
redaction.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Devon: even if changes are
incorporated in errata, it needs to be reflected technically
before it means anything.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Kirk: is that what happened to CAA
errata?<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Devon: errata doesn’t equal to
implementation.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Peter: implementation must happen
from both CA and Browser side. It must be deployed to all
customers and will takes long time to roll out. Do apple
check CT as well?<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Geoff: Yes<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Jeremy: Microsoft also check.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Geoff: but we will need to have
users update the mac OS.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Devon: what are behavior on EV certs
in CT in High Sierra?<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Geoff: in order to get EV treatment
in High Sierra and have to have CT<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Devon: which CT log does it support
for SCTs?<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Geoff: Apple has a list, but not
useable yet.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Curt: will create similar to Google
one.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Kirk: for CAs to bring up on
redaction, we will discuss offline.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<b><span style="color:black">Policy Review Working Group
Report</span></b><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Notetaker: Tim<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">The definitions of Trust Service
Provider and CA were discussed. It was proposed that
"logical entity" would make the definition clearer. Further
discussion will occur on the CABF public email thread.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">We need to go back and find the
thread where we identified which instances of CA in the BRs
refer to the service and which refer to the organization.
Very few instances refer to the organization.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Should the definition of CA state
that it is trusted by "one or more Application Software
Suppliers" instead of "one or more entities"? It's not
clear.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">"operated by the same TSP" vs
"affiliate"? Might handle after the CA bifurcation work is
done.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<b><span style="color:black">Review of pending ballots</span></b><span
style="color:black"><o:p></o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l18
level1 lfo18;background:white">
Reminder to include redlines with ballots<o:p></o:p></li>
</ul>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">206: "Governance Rule Change"<o:p></o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l19
level1 lfo19;background:white">
nothing to add<o:p></o:p></li>
</ul>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">207: "ASN.1 jurisdictionBlahBlah"<o:p></o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l3
level1 lfo20;background:white">
About to be introduced<o:p></o:p></li>
</ul>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">208: "dnQualifiers"<o:p></o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l5
level1 lfo21;background:white">
About to be introduced<o:p></o:p></li>
</ul>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">209: "EV Liability"<o:p></o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l20
level1 lfo22;background:white">
Allow CAs to have a per-cert total cap on liability<o:p></o:p></li>
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l20
level1 lfo22;background:white">
About to be introduced<o:p></o:p></li>
</ul>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">213: "Revocation timeline extension"<o:p></o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l14
level1 lfo23;background:white">
Pushing out the timelines for non-urgent revocations<o:p></o:p></li>
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l14
level1 lfo23;background:white">
Ryan wanted notification of the CAB Forum if it takes longer<o:p></o:p></li>
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l14
level1 lfo23;background:white">
Seems a bit stuck, but want to pass it<o:p></o:p></li>
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l14
level1 lfo23;background:white">
Robin and probably Kirk will endorse<o:p></o:p></li>
</ul>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">XXX: Remove "Any Other Method" from
IP Address Validation<o:p></o:p></span></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l22
level1 lfo24;background:white">
Looking for endorsers<o:p></o:p></li>
<li class="MsoNormal"
style="color:black;margin-bottom:11.0pt;line-height:normal;mso-list:l22
level1 lfo24;background:white">
People should read through it one more time<o:p></o:p></li>
</ul>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">XXX: Remove requirement to obey
latest version of the BRs<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<b><span style="color:black">Symantec EV Cert Discussion</span></b><span
style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Notetaker: Robin<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">For background to this issue, look
on the CABFMAN email list.<br>
The domain /FQDN is 0.me.uk/ev-phishing.<br>
The email subject is:<br>
Subject: [cabfman] Data for discussion of Symantec EV cert
article<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Kirk opened by asking the nature of
the problem with this certificate. The on-list discussion
seemed to center around the 'applicant place of existence'.
UK Companies House shows that address.<br>
Gerv: I was hoping SYMC would discuss this to determine
whether there were improvements we can make to the EV
guidelines.<br>
Kirk sent out that they have his name and a picture of his
house. One quote in the article ....<br>
Geoff: The original requirement was that he had a place
where they actually did business.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">PZB: is there a requirement that
SYMC discuss this?<br>
Gerv: my indications are that SYMC are willing to discuss,
so that Q is moot.<br>
Steve Medin: We see a request from a module peer as a
requirement.<br>
We regret that the investigation is taking a long time. We
believe this will lead to an improvement in the EVGL.<br>
Kirk: You said there is a problem. What is the problem?<br>
Gerv: Steve said there is a problem.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Geoff: The point is that if you have
business operations at that address it is harder to move.<br>
Steve: you can't just use a QGIS to prove 'operational
existence' - even by companies house. There is the potential
for some disappointment in some of the processes and there
may be a improvements required across the board to meet the
standard as it is currently stated.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<b><span style="color:black">Possible Root Program/BR Lint
testing requirement</span></b><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Notetaker: Robin<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Should we have a rule requiring lint
testing?<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Gerv: recently people have been
digging thru CT and fining issues with certs and creating
bugs. It is useful to see which CAs are on the ball. One
common thread is that CAs realizing that cablint and
x509lint are potent weapons so they incorporate them into
their issuance process. Kathleen was wondering whether it is
wise enough for it to be a program requirement or a BR
requirement. We would probably not mandate the use of
particular software. But if you don't do that, can you have
a requirement without teeth..?<br>
Tim: Doesn't that just end up being 'don't misissue.'<br>
Devon: It's a handy thing to lint, but we already have the
requirement to comply. Does it help to have a meta
requirement like that?<br>
Jeremy: I disagree. It's handy to have the requirement to
steer CAs to do it.<br>
Devon: You imply CAs aren't perfect?!?<br>
PZB: as an author of some of the software in question, ..
urges caution to require its use! There are bugs! It was
written for internal use.<br>
I'm somewhat disappointed in the use that has been made of
it to report findings in certificates from crt.sh.<br>
Gerv: From our perspective, we don't sweat the small stuff,
but it is useful because it flushed out one CA that doesn't
know what they're doing.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Robin: We run the tool against the
certificates we issue. Although PZB is correct to say no
tool is perfect, there is value in running the tool, but an
'exception' process is necessary.<br>
Gerv: If you get a finding from such a tool it is up to you
whether you choose to issue nonetheless. You have at least
made the determination. We drew attention to the existence
of these Lint tools in our last CA communication.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Jeremy: but new CAs come along.. A
recommendation could be useful.<br>
Gerv: we have a problematic practices and a best practices
page.<br>
Wayne: Could it be a MUST that prior to issuance a CA must
perform a check for technical compliance?<br>
Curt: Doen't we already have that requirement by auditing?<br>
Wayne: Post issuance<br>
Devon: But we have requirements, CAs must follow
requirements already.<br>
Gerv: I guess we should just add this to our best practices
page.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<b><span style="color:black">Discussion of Mozilla BR
self-assessment experience</span></b><span
style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Notetaker: Robin<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Gerv: Kathleen ponders a suggestion
that CAs that haven't done a self-assessment recently should
do one. Is it fair to say that, for each CP/CPS pair, you
would need a separate assessment? So our request may be 'can
you do N self-assessments'.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">A BR audit maps each requirement of
the BRs to the CP/CPS.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Aaron checks before inclusion that a
CAs documentation is adequate and BR compliant. It used to
be that we went through the CP and CPS and did the
mapping. Now we get the new CA to do the mapping as a
self-assessment.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Gerv: SSL.com - you are in the
inclusion process. Can you give us a rough idea how many man
hours the self-assessment took?<br>
Leo: several weeks elapsed time.<br>
Gerv: So of the order of a man-week?<br>
Leo: - that would be fair.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Straw poll shows no-one had more
than 3 CP/CPS pairs.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">ben: what about a CP/CPS combo that
just maps to the BRs?<br>
Gerv: We say that you can't just the dump the BRs into your
CP/CPS for 3.2.2.4.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Kirk: It could be useful to help a
CA find gaps in their own process.<br>
But I don't want to subsequently hear from the browsers that
'You said in your SA that you did 7.1.4, but we found that
you don't. Double whammy.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Gerv: That is not the intent.<br>
Devon: How many people are there on the planet whose job it
is to map CP/CPS to BR audit criteria? 10?<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Gerv: Having the CA doing the
mapping makes the process of CP/CPS evaluation much easier
at the time when it comes to admit a CA to a root program.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Kirk: Maybe as we post a new version
of our CPS, the self-assessment could be tied to that.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Robin: It's got to be useful to have
more eyes on a CP/CPS. You can't review your own code! As
Jeff Ward pointed out yesterday, the CA's auditor will
already have done the mapping as part of their annual audit
work. Do we just end up handing over our auditors' mappings?<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Gerv: OK, so I haven't made you do
an incredible amount of work.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Robin: Small amount of incremental
value, for a small amount of work?<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Geoff: The interesting thing is the
ratio between the work done and the value derived.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Gerv: I will take this back to
Kathleen.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<b><span style="color:black">Information about next F2F
Meeting 43 hosted by Amazon in Herndon, VA, USA – March
6-8, 2018</span></b><span style="color:black"><o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Notetaker: Kirk<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Peter confirmed the next F2F meeting
will be hosted by Amazon on March 6-8, 2018 at its Herndon,
Virginia location. More information will be provided in the
coming months.<o:p></o:p></span></p>
<p class="MsoNormal"
style="margin-bottom:11.0pt;line-height:normal;background:white">
<span style="color:black">Kirk said that both Cupertino, CA
and London had been suggested for the June 2018 meeting, and
asked for a straw poll of preference. Gerv asked where the
Fall 2018 meeting would be, and Kirk said China. Gerv said
that London seemed the better choice for a June meeting, as
that balances meetings among Europe, North America, and
Asia, and the group's consensus was the same. The June 2018
meeting will be hosted by Comodo in London. Kirk asked other
members to talk to him if they wanted to host a meeting in
2019.<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:11.0pt"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
<br>
</body>
</html>