<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 12px; font-family: Arial, sans-serif; "><div><div><div><div style="font-family: Arial, sans-serif; font-size: 12px; "><div>Hi Kirk,</div><div><br></div><div>What I was attempting to show with the practical (and painstaking) exercise of making 50+ examples was that certificates are extremely 'flexible' and so therefore are browsers in how they have evolved to interpret them.  This means that there's an array of possible moving parts to consider which can be both included or excluded resulting in the smorgasbord of alternatives we see today.  </div><div><br></div><div>The vast assortment of alternatives is mainly to the detriment of understanding by relying parties using todays browsers/certificate viewers.  How should we expect the browsers to be able to sift through the information and all possible combinations, decide which parts are most relevant, and then finally show these in the most effective manner to relying parties?   CA's need to first establish a constant baseline such that we can then petition browsers to show relevant information to relying parties.</div><div><br></div><div>You keep repeating your security question and I keep repeating my answer.   My concern is not with the security issues here, but with consistency of practice towards relying parties and subscribers. The EV guidelines AND the Base Requirements were crafted to address BOTH security and certificate structure best practice from CAs towards relying parties and subscribers and not just one element.  If all provisions simply had to pass the litmus test of security we would not have been able to get to where we are today.</div><div><br></div><div>So let me try to answer your security question by taking the example of 2 DV certs on 2 IPs with two owners (not 10).  Let's assume one is <b>www.bankofamerica.com</b> (Actually owned by <b>Bank of America</b>) and one is <b>www.bobsbits.com</b> (Actually owned by Robert Doe).</div><div><br></div><div>With two 'separate' DV certificates Robert's customers cannot see/decrypt any information sent to Bank or America's customers (unless due to <b>bad security practice</b> keys are replicated)  SNI allows these to exist on the same IP and the type of service is completely arbitrary to the discussions – rather like trying to say a service is e-commerce or not we cannot and therefore should not try to pin it down.</div><div><br></div><div>With a single DV certificate (therefore a shared key) both customers can see/decrypt all information.</div><div><br></div><div>So what is placed into the common name? (Nothing is the proposed best practice)</div><div>So what is placed into the initial SAN? www.bobsbits.com?</div><div><br></div><div>The elephant in the room here is does Bank of America know that they share keys with Robert?  (i.e. From a subscriber perspective).  i.e. Has the CA been diligent enough to say to all parties (When they obtained domain control proof) did you really know you are sharing keys/services with all these additional entities/domain owners/people who control a domain.</div><div><br></div><div>So either the CA needs to verify that ALL domains are owned by the same party (EV presents the only method acceptable to date by looking at WHOIS or contacting the registrar) and choose to leave that information out, or include the details of the party that controls the domains on behalf of all the real owners.</div><div><br></div><div>If everyone finds it acceptable that positive domain control is completely independent of all other tests/assurances (i.e. a positive response to any challenge) then this needs to be reflected into the EV guidelines too.</div><div><br></div><div>Please think of the issue we have with our conference calls.  Ben gives out the details and takes a register of attendees.    Many would object if suddenly the line was shared with entities we did not recognise/trust.</div><div><br></div><div>I'll work with the other endorsers to amend the language to address smaller concerns raised but in general I want this to proceed along the same lines.</div><div><br></div><div>Steve</div><div><br></div></div></div><div><div><div><p></p><font class="Apple-style-span" style="color: rgb(0, 0, 0); "><font class="Apple-style-span"><p style="font-family: Arial, sans-serif; color: rgb(0, 0, 0); font-size: 14px; "></p></font></font></div></div></div></div></div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> "<a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>" <<a href="mailto:kirk_hall@trendmicro.com">kirk_hall@trendmicro.com</a>><br><span style="font-weight:bold">Date: </span> Sunday, 4 November 2012 16:52<br><span style="font-weight:bold">To: </span> "CABFPub (<a href="mailto:public@cabforum.org">public@cabforum.org</a>)" <<a href="mailto:public@cabforum.org">public@cabforum.org</a>>, CABForum Management <<a href="mailto:management@cabforum.org">management@cabforum.org</a>><br><span style="font-weight:bold">Subject: </span> Re: [cabfman] [cabfpub] Ballot 92 - Certificate examples to aid discussions.<br></div><div><br></div><div 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"><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: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;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:12.0pt;
        font-family:"Times New Roman","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;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
        {mso-style-priority:99;
        mso-style-link:"Plain Text Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri","sans-serif";}
p
        {mso-style-priority:99;
        mso-margin-top-alt:auto;
        margin-right:0in;
        mso-margin-bottom-alt:auto;
        margin-left:0in;
        font-size:12.0pt;
        font-family:"Times New Roman","serif";}
span.apple-style-span
        {mso-style-name:apple-style-span;}
span.EmailStyle19
        {mso-style-type:personal-reply;
        font-family:"Calibri","sans-serif";
        color:#1F497D;}
span.PlainTextChar
        {mso-style-name:"Plain Text Char";
        mso-style-priority:99;
        mso-style-link:"Plain Text";
        font-family:"Calibri","sans-serif";}
.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]--><div lang="EN-US" link="blue" vlink="purple"><div class="WordSection1"><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; ">I’m not sure what your message below and attachments are meant to demonstrate – but it appears to be more of a browser problem than a CA problem.  I’ll let
 the browsers respond to that.<o:p></o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p> </o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; ">I asked the sponsors to respond to the question below, and Jeremy deferred to you as the author of this part of Ballot 92.  I don’t think your message below
 is responsive.  Can you tell us if you see a security difference, and if so, why?<o:p></o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p> </o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; ">Here is the basic question which needs answering:<o:p></o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p> </o:p></span></p><p class="MsoPlainText">What is the difference between 10 DV certs (each for a single domain) where domain control was proved for each with a single customer (either someone who owned all 10 domains, or an ISP/hosting company who controlled all 10 domains),
 versus a DV SANs cert with the same 10 domains inside (owned by one party or controlled by an ISP or hosting company), where domain control was proved for each with a single customer? 
<o:p></o:p></p><p class="MsoPlainText"><o:p> </o:p></p><p class="MsoPlainText">It appears to me they are equivalent from a security standpoint.<o:p></o:p></p><p class="MsoPlainText"><o:p> </o:p></p><p class="MsoPlainText">If we force customers to buy OV certs if they want multiple domains inside, we will be adding cost and delay for no added security.<o:p></o:p></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p> </o:p></span></p><p class="MsoNormal"><span style="font-size: 11pt; color: rgb(31, 73, 125); font-family: Calibri, sans-serif; "><o:p> </o:p></span></p><div><div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; ">From:</span></b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; "> <a href="mailto:public-bounces@cabforum.org">public-bounces@cabforum.org</a> [<a href="mailto:public-bounces@cabforum.org">mailto:public-bounces@cabforum.org</a>]
<b>On Behalf Of </b>Steve Roylance<br><b>Sent:</b> Friday, November 02, 2012 9:05 AM<br><b>To:</b> CABFPub (<a href="mailto:public@cabforum.org">public@cabforum.org</a>)<br><b>Subject:</b> [cabfpub] Ballot 92 - Certificate examples to aid discussions.<o:p></o:p></span></p></div></div><p class="MsoNormal"><o:p> </o:p></p><div><div><div><p class="MsoNormal"><span style="font-size: 9pt; color: black; font-family: Arial, sans-serif; ">Dear all.<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="font-size: 9pt; color: black; font-family: Arial, sans-serif; "><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span style="font-size: 9pt; color: black; font-family: Arial, sans-serif; ">It seems that many people were confused about the Intent of Ballot 92.   <o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="font-size: 9pt; color: black; font-family: Arial, sans-serif; "><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span style="font-size: 9pt; color: black; font-family: Arial, sans-serif; ">Even though Jeremy illustrated some examples during the discussions (thanks!) and even though the ballot itself features examples, I felt that it would be beneficial
 to all parties to come to an agreement on the scope of the problem and therefore to provide an illustration of the alternative mix of domains/IPs/Shortnames that we are trying to encompass.<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="font-size: 9pt; color: black; font-family: Arial, sans-serif; "><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span style="font-size: 9pt; color: black; font-family: Arial, sans-serif; ">Please see the attached XLS (and PDF version).<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="font-size: 9pt; color: black; font-family: Arial, sans-serif; "><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span style="font-size: 9pt; color: black; font-family: Arial, sans-serif; ">I've illustrated several different combinations of public/non public domains.  In order to allow everyone to visualise (in their favourite certificate viewer) just
 how things stand I've also provided certificates, PKCS12's keys and requests.  These are in the ZIP file and are labelled as per the XLS sheet so you should be able to quickly and easily identify a specific combination of components you may be concerned about
 and obtain an example.  i.e. DV 1-13, OV 1-10 and Controversial 1-4.<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="font-size: 9pt; color: black; font-family: Arial, sans-serif; "><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span style="font-size: 9pt; color: black; font-family: Arial, sans-serif; ">I've also provided a few screen shots in a 2nd PDF to highlight how the Windows Certificate Viewer makes a 'best attempt' to display information to relying parties.
  i.e. When there is no CN it reverts to the next OU.    My intention here is not to ballot how the browsers show certificates but to indicate that both the browsers and CAs need to work together to improve the situation for relying parties and I'm happy to
 try to move the CAs forward first.  After all, it's the CAs who attest to the combination of the various component parts of the certificate by signing it, so Browsers will never be able to move forward whilst CAs don't have a solid baseline of when and when
 not to include additional Subject DN Information.<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="font-size: 9pt; color: black; font-family: Arial, sans-serif; "><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span style="font-size: 9pt; color: black; font-family: Arial, sans-serif; ">The majority of the feedback I received last week seems to highlight that mixed 'DV' domains are contentious hence the 1-4 in the sheet.  Some think that it's fine
 to allow multiple owners to be bundled in to a single certificate.  I do not think this is acceptable.   I'm sure that some of the supporters of this motion will be able to add additional weight to the argument in terms of private key control, however as I
 have always stated, my focus is on what replying parties are able to see today and CAs can certainly improve this.<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="font-size: 9pt; color: black; font-family: Arial, sans-serif; "><o:p> </o:p></span></p></div><div><div><div><p class="MsoNormal"><span style="font-size:9.0pt;color:black">Kind Regards<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="font-size:9.0pt;color:black"><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span style="font-size:9.0pt;color:black">Steve<o:p></o:p></span></p></div><div><p class="MsoNormal"><span style="font-size:9.0pt;color:black"><o:p> </o:p></span></p></div><div><p class="MsoNormal"><span style="font-size:9.0pt;color:black">P.S. If you want a particular combination of components adding them please let me know.  Additional SAN entries beyond 2 only complicate things further and are effectively subsets of the examples
 created.  I didn't have the chance to make CRLs etc so some browsers balk – We can address this over the coming days/weeks prior to a resubmission of the ballot.<o:p></o:p></span></p></div><div><p class="MsoNormal" style="line-height:12.75pt"><span class="apple-style-span"><span style="font-size: 9pt; color: black; font-family: Arial, sans-serif; "> </span></span><span style="font-size: 10.5pt; color: black; font-family: Calibri, sans-serif; "><o:p></o:p></span></p><p class="MsoNormal" style="line-height:12.75pt"><span style="color:black"><o:p> </o:p></span></p></div></div></div></div></div></div></div></div><table><tbody><tr><td bgcolor="#ffffff"><font color="#000000"><pre><table class="TM_EMAIL_NOTICE"><tbody><tr><td><pre>TREND MICRO EMAIL NOTICE
The information contained in this email and any attachments is confidentialand 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></tbody></table></pre></font></td></tr></tbody></table>
_______________________________________________
Management mailing list
<a href="mailto:Management@cabforum.org">Management@cabforum.org</a>
<a href="https://cabforum.org/mailman/listinfo/management">https://cabforum.org/mailman/listinfo/management</a>
</span></body></html>