<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
{font-family:"MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"Bradley Hand ITC";
panose-1:3 7 4 2 5 3 2 3 2 3;}
@font-face
{font-family:"\@MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri","sans-serif";}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Here’s an idea for moving forward on Ballot 149, which was intended to update our Bylaw 2.1 on membership rules. Most of the draft ballot is uncontroversial, but one part has drawn opposition from Gerv and Ryan.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>BACKGROUND<o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Our original Bylaw 2.1 has a number of requirements, including that the CA applicant “has
<s>a</s> current and successful WebTrust for CAs audit”. (Please read in “or ETSI equivalent” for the rest of this email.) That Bylaw was adopted
<u>before</u> the BR WebTrust audit guidelines were completed, and before any browser started requiring a BR WebTrust audit.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Here is the <u>current</u> Bylaw as applied to a root CA (similar rules for an Issuing CA):<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><u><span lang="EN" style="color:black">“Root CA</span></u><span lang="EN" style="color:black">: The member organization operates a certification authority that has a current and successful
</span><span lang="EN" style="border:none windowtext 1.0pt;padding:0in">WebTrust</span><span lang="EN" style="color:black"> for CAs, or ETSI 102042 or ETSI 101456 audit report prepared by a properly-qualified auditor, and that actively issues certificates to
subordinate CAs that, in turn, actively issue certificates to Web servers that are openly accessible from the Internet using any one of the mainstream browsers.”</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Two things changed after that Bylaw was adopted. First, the name “WebTrust for CAs” changed (it is now changing back). Second, most or all of the main browser root programs have added a second requirement that the CA
<i><u>also</u></i> have a valid and current <i><u>BR</u></i> WebTrust audit, in addition to a WebTrust for CAs audit.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The changes in this part of my ballot draft were simply intended to update the membership audit requirements to cover both WebTrust and BR WebTrust, and update the names. My thinking was a CA can’t be a real CA unless it has roots in the
browsers, and you can’t have roots in the browsers any more unless you have both audits because that is what the browsers require.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Gerv and Ryan objected to adding the requirement of a BR WebTrust audit on the grounds (as I understand it) that because the BRs are a product of the Forum itself, it would not be proper to add the requirement of a BR WebTrust audit as
a condition to membership in the Forum (even if a BR WebTrust audit is a requirement to getting your roots in the browsers). I don’t share that view, but think we can work around it.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">There is another problem with our current rule – government CAs. Some browsers permit government CAs to be audited by a government auditor (not WebTrust or ETSI) and have its roots in the browser. Our current Bylaw would not allow a government
CA to be a Forum member, which we should probably fix.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>NEW PROPOSAL<o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">To get around this issue, we could drop specific membership requirements tied to
<u>audits</u>, and instead assume that if multiple <u>browser</u> members of the Forum have allowed the applicant to include at least one root in their browsers, that is sufficient (as we assume the browsers will impose appropriate audit requirements). This
would also open membership to government CAs that don’t have WebTrust or ETSI audits.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">In concept, my proposal is that any CA with <u>at least one root</u> in the trusted root store of
<u>at least two browser members of the CA-Browser Forum</u> who maintain independent root stores can become a member, if they satisfy all the other requirements. I suggest two browser members because the day could come when a single browser member drops all
audit requirements, etc. Also, it’s hard to see a CA that has a root in only a single browser as being a viable CA.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The membership language for a Root CA would change to something like the following:<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><u>Root CA:</u> The member organization operates a certification authority
<i><s>that has a current and successful WebTrust for CAs audit or ETSI 102042 or ETSI 101456 audit report prepared by a properly-qualified auditor, and</s></i> that actively issues certificates to subordinate CAs that, in turn, actively issue certificates to
Web servers that are openly accessible from the Internet using <b><u>the browser or application of any two browser members of the Forum that maintain an independent trusted root store
</u></b><i><s>any one of the mainstream browsers</s></i>. <o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in">[As edited:]<o:p></o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-left:.5in"><u>Root CA:</u> The member organization operates a certification authority that actively issues certificates to subordinate CAs that, in turn, actively issue certificates to Web servers that are openly accessible
from the Internet using the browser or application of any two browser members of the Forum that maintain an independent trusted root store.
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">We would make a similar change for our application rules for the “Issuing CA” membership category.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">There are at least two advantages from this new approach. First, we don’t have to keep updating the specific WebTrust/ETSI audit names and numbers every time there is a change. Second, this would open up membership to government CAs who
may not have a WebTrust/ETSI audit but have roots in the browsers.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">The rest of the ballot would be as before.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b>REQUEST FOR FEEDBACK<o:p></o:p></b></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I’d appreciate feedback. We can also discuss on this Thursday’s call.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b><i><span style="font-size:14.0pt;font-family:"Bradley Hand ITC";color:#0F243E">Kirk R. Hall<o:p></o:p></span></i></b></p>
<p class="MsoNormal">Operations Director, Trust Services<o:p></o:p></p>
<p class="MsoNormal">Trend Micro<o:p></o:p></p>
<p class="MsoNormal">+1.503.753.3088<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</body>
</html>
<table><tr><td bgcolor=#ffffff><font color=#000000><pre><table class="TM_EMAIL_NOTICE"><tr><td><pre>
TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidential
and may be subject to copyright or other intellectual property protection.
If you are not the intended recipient, you are not authorized to use or
disclose this information, and we request that you notify us by reply mail or
telephone and delete the original message from your mail system.
</pre></td></tr></table></pre></font></td></tr></table>