<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:Cambria;
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;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
margin-bottom:.0001pt;
font-size:10.0pt;
font-family:"Courier New";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:"Courier New";}
span.EmailStyle20
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:windowtext;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri","sans-serif";
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Jeremy, I know Ballot 92 has been withdrawn, but I expect it will be reintroduced – so we may as well continue the conversation.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Concerning your proposed changes to Sec. 9.2.1 outlawing DV SANs certs, I am still puzzled about what security threat is being addressed. In your email below, you listed a hypothetical 12 names that could be included in the SANs field
of a single DV cert (so long as the customer has demonstrated domain control for each of the 12 names).
<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Are you saying this single DV SANs cert with 12 names inside (all of which have passed the domain control test with the customer) represents a
<u>greater</u> security threat than if the <u>same</u> customer had ordered 12 <u>
separate</u> DV certs, each with only one name inside, and had proved domain control for each of the 12 names? In what way does the DV SANs cert with 12 names inside represent a greater security threat than 12 individual DV certs issued to the same customer?
(I don’t believe it does.) We have to consider the convenience of the customer, and not put artificial barriers or unnecessary extra expense in the way.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">You also talk about the need for one of the 12 names to go through the OV vetting process so there is an identified “responsible party” inside the cert (does that make it an OV cert then? The CA issuer knows that 11 names have not been
OV vetted…). But I think that would be very misleading to Relying Parties – If they look inside the cert with 12 names in the SANs field, and they see an OV-vetted entity’s identity listed in the cert, they will probably assume that ALL 12 NAMES in the cert
have been OV vetted, and that all 12 names belong to the one entity that is listed in the cert. But only one domain name was OV vetted, and the remaining 11 were only DV vetted. That would be terribly misleading to the public, and a bad idea.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">We don’t issue DV certs, and have no plans to do so, but we strongly oppose any new effort to deprecate DV certs using the Forum’s powers to set requirements for CAs. I hope you will drop this from Ballot 92, or else the other provisions
of the ballot (some of which we support) will possibly fail as well.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">********************************************************<o:p></o:p></p>
<p class="MsoNormal"><span style="color:#1F497D"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif"">From:</span></b><span style="font-size:10.0pt;font-family:"Tahoma","sans-serif""> public-bounces@cabforum.org [mailto:public-bounces@cabforum.org]
<b>On Behalf Of </b>Jeremy Rowley<br>
<b>Sent:</b> Thursday, October 25, 2012 2:08 PM<br>
<b>To:</b> public@cabforum.org<br>
<b>Subject:</b> [cabfpub] Ballot 92 reviewed<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif"">Hi everyone, <o:p>
</o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif"">Ballot 92 addresses the concerns listed below. These issues have been discussed since at least February of 2012 through various email exchanges. Kirk Hall asked for a summary explanation of
why we consider these changes necessary. This summary is intended only to explain the purpose of the ballot and is not intended to modify the ballot in any manner.
<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><b><span style="font-family:"Cambria","serif"">Section 9.2.1 - Subject Information<o:p></o:p></span></b></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif"">Section 9.2.1was modified to require subject information in a certificate containing multiple root domain names. DV certs are still permitted if the certificate will contain multiple subdomains
off the same root domain. Subject information is also required for certificates that contain a reserved server name or IP address.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif"">This change is necessary because, in certain cases, certificates with multiple domains (SANs) owned by unrelated parties present security problems when no identifying information has been obtained.
Take for instance a DV certificate with multiple SANs as follows: <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif"">OBJECT IDENTIFIER : subjectAltName [2.5.29.17]<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif"">CONTEXT SPECIFIC (2) : 'xyx.whoami.com'<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif"">CONTEXT SPECIFIC (2) : 'www.microswift.com'
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif"">CONTEXT SPECIFIC (2) : 'xyz'<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif"">CONTEXT SPECIFIC (2) : 'students.fullerton.edu'<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif"">CONTEXT SPECIFIC (2) : 'www.paypal.local'<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif"">CONTEXT SPECIFIC (2) : '10.0.0.101'<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif"">CONTEXT SPECIFIC (2) : 'shareholder.gecapital.com'<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif"">CONTEXT SPECIFIC (2) : 'amazon.ez-seller.com'<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif"">CONTEXT SPECIFIC (2) : 'www.google.dom'
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif"">CONTEXT SPECIFIC (2) : 'fasthost.com'<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif"">CONTEXT SPECIFIC (2) : 'authentic.bad-girl.com'<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif"">CONTEXT SPECIFIC (2) : 'score.nuthinbut.net'<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif"">It’s hard to tell who the responsible party is. (By way of analogy, under traditional limited partnership law, there is always at least one General Partner when the rest of the partners are Limited
Partners.) <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif"">So even assuming that we’re sunsetting certificates with private IP addresses or internal server names, there has never been a decision to not make other related improvements to the security of
certificates where necessary. Certain information should be prohibited in the CN field and that certificates containing internal server names should have additional restrictions, and possibly full Organizational Vetting (regardless of whether such information
is contained in the certificate) for the following reasons: <o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif"">Prior to v1.0 of the baseline requirements, the CN field could contain information other than an FQDN, but allowing a private IP or non-FQDN might result in an incorrect interpretation of the
information in this field and create a potential attack. The CN field’s multi-purpose use is one of the reasons the field was deprecated, and the Forum shouldn’t permit uses of this field that resemble an organization name instead of an FQDN.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif"">A certificate with a non-FQDN or private IP address is essentially non-verified if the certificate lacks organization details. Providing a certificate without verified information might enable
an attacker to perform a MITM attack. Conversely, if a verified O field were included, that would provide a way to distinguish between various mail.server certificates held by different organizations.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif""><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-family:"Cambria","serif"">As illustrated above, a certificates containing multiple registered domains must be tied to at least one specified entity. Including multiple unrelated domains in a single certificate just amplifies
the potential damage caused by a single mis-issued certificate. Multiple domains are now a central part of virtualization, and certificates with multiple domain names should be additionally protected. Requiring the listing of an organization in certificates
with multiple root domains ties the certificate to a verified owner, which is a protection against fraud. Requiring OV (for at least one entity) helps monitor and/or communicate with all of the other entities receiving and using such certificates. A certificate
with a lot of high profile domains is worrisome if contextual organizational contact information is missing. When that information is absent, then relying parties are at the mercy of the issuing CA, who may be unwilling to share that contact information because
the relying party is not “the customer” in the minds of some CAs. <o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="color:#1F497D">***<o:p></o:p></span></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>