<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=utf-8"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:新細明體;
panose-1:2 2 5 0 0 0 0 0 0 0;}
@font-face
{font-family:新細明體;
panose-1:2 2 5 0 0 0 0 0 0 0;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@新細明體";
panose-1:2 2 5 0 0 0 0 0 0 0;}
@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:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"新細明體","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;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.shorttext
{mso-style-name:short_text;}
span.EmailStyle19
{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:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;}
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=ZH-TW link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span lang=EN-US style='font-family:"Calibri","sans-serif";color:#1F497D'>Peter, <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Calibri","sans-serif";color:#1F497D'>Microsoft Trusted Root Certificate: Program Requirements 4. Program Technical Requirements has below requirement: <o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Calibri","sans-serif";color:red'>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><span lang=EN-US style='font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal style='text-indent:12.0pt'><span lang=EN-US style='font-family:"Calibri","sans-serif";color:#1F497D'> </span><span lang=EN-US style='font-family:"Calibri","sans-serif";color:#1F497D'>Li-Chun CHEN<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> </span><span style='font-size:10.0pt'>陳立群</span><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> [mailto:realsky@cht.com.tw] <br><b>Sent:</b> Friday, July 22, 2016 9:58 PM<br><b>To:</b> 'Ryan Sleevi'; 'Peter Bowen'<br><b>Cc:</b> 'CABFPub'<br><b>Subject:</b> RE: [cabfpub] Increasing concurrent compliance compatibility<o:p></o:p></span></p></div></div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Calibri","sans-serif";color:#1F497D'> We agree with Ryan’s thought that Peter’s new proposal may create a rather large loophole for potential abuse/mistakes.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Calibri","sans-serif";color:#1F497D'> The proposal will also let Dean’s leading to encourage to use CABF EV/OV/IV/DV OID instead of CA’s CP OID of EV/OV/IV/DV OID delaying progress.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal style='text-indent:12.0pt'><span lang=EN-US style='font-family:"Calibri","sans-serif";color:#1F497D'>We suggest to choose Ben’s or Wen-Cheng’s proposed versions to amend section 7.1.4.2.2 d & e to solve small countries /jurisdictions do not set up any state or province (or they follow their law, or X.520, or organizationName is already unique at the country level. ). Their versions will not affect CAs that issues OV/IV SSL certificates in countries/jurisdictions that have set up state/province or CAs that identify Origination / Individual by physical address.<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal style='text-indent:12.0pt'><span lang=EN-US style='font-family:"Calibri","sans-serif";color:#1F497D'>Besides, I just curious about US Federal PKI’s entities certificates Distinguished Name, Peter , could you explain it? Thank you.<o:p></o:p></span></p><p class=MsoNormal style='text-indent:12.0pt'><span lang=EN-US style='font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal style='text-indent:12.0pt'><span lang=EN-US style='font-family:"Calibri","sans-serif";color:#1F497D'>Li-Chun CHEN<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='font-family:"Calibri","sans-serif";color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span lang=EN-US style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> public-bounces@cabforum.org [mailto:public-bounces@cabforum.org] <b>On Behalf Of </b>Ryan Sleevi<br><b>Sent:</b> Friday, July 22, 2016 5:53 AM<br><b>To:</b> Peter Bowen<br><b>Cc:</b> CABFPub<br><b>Subject:</b> Re: [cabfpub] Increasing concurrent compliance compatibility<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p><div><p class=MsoNormal><span lang=EN-US>On Thu, Jul 21, 2016 at 2:24 PM, Peter Bowen <<a href="mailto:pzb@amzn.com" target="_blank">pzb@amzn.com</a>> wrote:<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US>I propose that we amend the BRs to change the </span>“<span lang=EN-US>trigger</span>”<span lang=EN-US> for OV/IV to be the explicit inclusion of the appropriate CA/B Forum policy identifier rather than an implicit trigger based on attributes found in the Subject distinguished name.<br><br>This would allow CAs who are issuing certificates that need to comply with both the BRs and other certificate policies the ability to set the subject distinguished name as needed. For example, some CAs may need to follow X.521 for the DN while others may need to use the country, state/province, and locality attributes to indicate legal jurisdiction rather than physical address and others may need to ensure that each legal or natural person has a distinct DN.<br><br>Concretely, if a certificate has one or both of:<br>{joint</span>‐<span lang=EN-US>iso</span>‐<span lang=EN-US>itu</span>‐<span lang=EN-US>t(2) international</span>‐<span lang=EN-US>organizations(23) ca</span>‐<span lang=EN-US>browser</span>‐<span lang=EN-US>forum(140) certificate</span>‐<span lang=EN-US>policies(1) baseline</span>‐<span lang=EN-US> requirements(2) organization</span>‐<span lang=EN-US>validated(2)} (2.23.140.1.2.2)<br>{joint</span>‐<span lang=EN-US>iso</span>‐<span lang=EN-US>itu</span>‐<span lang=EN-US>t(2) international</span>‐<span lang=EN-US>organizations(23) ca</span>‐<span lang=EN-US>browser</span>‐<span lang=EN-US>forum(140) certificate</span>‐<span lang=EN-US>policies(1) baseline</span>‐<span lang=EN-US> requirements(2) individual</span>‐<span lang=EN-US>validated(3)} (2.23.140.1.2.3)<br>in its certificate policies extension, then the current BR requirements apply to the subject DN.<br><br>If neither are in the certificate policies extension, then the only Subject DN restriction would be on the commonName (CN) attribute. All other attributes would be set according to the non-CABF policy for the certificate<br><br>I believe this would help resolve the issues Li-Chen has raised and I think it would help existing PKIs, such as the US Federal PKI, align their policies with the CABF BRs.<br><br>Anyone agree or disagree?<br><br>Thanks,<br>Peter<o:p></o:p></span></p><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>Doesn't this create a rather large loophole for potential abuse/mistakes?<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>For example, I'm not aware of any browser that specifically recognizes the OV OID, but all display the organization information in some way, most commonly as some short-name in some form of UI. As proposed, if a CA didn't assert the OV OID, then it would seem reasonable that a CA might decide that no policies apply, and put "Google, Inc" in the O field.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>Is that desirable? Is that right?<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>It's unclear whether CAs reasonably understand 7.1.2.4 (b), or whether that clearly prohibits that - or if it even should.<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>Similarly, what happens to 7.1.4.2.2 (i)? Do you see that being exempt?<o:p></o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US><o:p> </o:p></span></p></div><div><p class=MsoNormal><span lang=EN-US>Given Relying Party applications' longstanding and preexisting use of the fields (in particular, those noted in 7.1.4.2.2 a-h), I'm concerned with the introduction of semantics that would, in effect, change the meaning based on the policies asserted. If we were starting over from scratch, I would think it'd be an entirely reasonable suggestion, but given the preponderance of legacy systems in place, it seems slightly troublesome on principle to allow 'caveat CA' to rule here.<o:p></o:p></span></p></div></div></div></div></div></body></html><br><html><div><div>本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任. </div><div>Please be advised that this email message (including any attachments) contains confidential information and may be legally privileged. If you are not the intended recipient, please destroy this message and all attachments from your system and do not further collect, process, or use them. Chunghwa Telecom and all its subsidiaries and associated companies shall not be liable for the improper or incomplete transmission of the information contained in this email nor for any delay in its receipt or damage to your system. If you are the intended recipient, please protect the confidential and/or personal information contained in this email with due care. Any unauthorized use, disclosure or distribution of this message in whole or in part is strictly prohibited. Also, please self-inspect attachments and hyperlinks contained in this email to ensure the information security and to protect personal information.</div></div><div><br></div><div><br></div></html>