<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:"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;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
{font-family:"\@新細明體";
panose-1:2 2 5 0 0 0 0 0 0 0;}
/* 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;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
{mso-style-priority:99;
mso-style-link:"註解方塊文字 字元";
margin:0cm;
margin-bottom:.0001pt;
font-size:9.0pt;
font-family:"Cambria","serif";}
span.EmailStyle17
{mso-style-type:personal;
font-family:"Calibri","sans-serif";
color:#1F497D;}
span.a
{mso-style-name:"註解方塊文字 字元";
mso-style-priority:99;
mso-style-link:註解方塊文字;
font-family:"Cambria","serif";}
span.EmailStyle20
{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">Folks,<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">Below are some discussions about AIA support and problem regarding key rollover with self-issued certificates. Here I would like to forward the contents of the
discussions to the mailing list and wish to evokes some resonance in the forum.<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">Wen-Cheng Wang<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-family:"Calibri","sans-serif";color:#1F497D">Chunghwa Telecom Co., Ltd<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"">
<br>
<b>Sent:</b> Monday, June 22, 2015 9:21 PM<br>
<b>To:</b> 'Ryan Sleevi'; </span><span style="font-size:10.0pt">陳立群</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""><br>
<b>Cc:</b> </span><span style="font-size:10.0pt">江彬榮</span><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""><br>
<b>Subject:</b> RE: Introduce Chunghwa Telecom's representative to join 35th F2F meeting in Zurich<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">Ryan,<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">Thank you for your suggestions.<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">We certainly know that “AIA not supported by non-IE browsers” is not the root cause of our SSL certificate path problem. We simply think AIA is a good mechanism
and browsers should consider to adopt it to improve users’ experiences. Let’s put aside our SSL certificate path problem first. In our customer service experiences, even with a simple 3-leve certificate path (i.e., root CA cert -> subordinate CA cert -> SSL
cert) and well-documented SSL certificate path installation instructions, it is not uncommon that web server administrators forgot to install subordinate CA certificates in their SSL server configurations. The results were users of most browsers, except IE
and Chrome-for-Windows, encountered broken certificate path during SSL/TLS handshake. End users did not know that those are web server administrators’ faults but they might simply think IE do the job better than other browsers. On the other hand, web server
administrators who encountered broken certificate path issues often ask our technical supports. In most cases, web server administrators did not understand SSL/TLS handshake well and we told them the causes were that they did not correctly install subordinate
CA certificates in their SSL server configurations. It is not uncommon either that web server administrators argue that they used IE to test the SSL/TLS connection and it worked well so they think that those are not their faults. We had to explain to them
that IE worked well because it support AIA (of course, we had to explain to them what AIA is, too) and unfortunately not all browsers support AIA, therefore they need to correctly install subordinate CA certificates in their SSL server configurations to solve
the broken certificate path issues.<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">Speaking of our approach to PKI (i.e., our certificate hierarchy), I really feel sad that your comment is ‘the deployment path chosen is one that does not work
nor has ever worked well with applications.’ I believe that our approach definitely conforms to PKIX standards. For the root key rollover, we followed the procedures defined in section 4.4 of RFC 4210 (the Certificate Management Protocol) and adopted the self-issued
certificate defined in RFC 5280 (the PKIX certificate and CRL profiles). I had ever spend a lot of time to participated the development of PKIX standards, especially RFC 5280. I respect the standards and I believe that every implementation should follow the
standards to promote interoperability. It is unfortunate that some web server implementations such as IIS failed to distinguish self-issued certificates from self-signed certificates. In RFC 5280, a self-issued certificate is a certificate with the same Distinguished
Name (DN) appears in the subject and issuer fields but might be signed with different keys. This is carefully defined to support the root key rollover procedures defined in RFC 4210. Also, the certificate path validation algorithm defined in section 6.1 of
RFC 5280 was carefully designed to handle the situations where self-issued certificates appear in the certificate paths. The problem is that some implementers of servers or applications mistakenly thought that a certificate with the same Distinguished Name
(DN) appears in the subject and issuer fields is always a self-signed certificate. This kind of implementation is certainly wrong from the viewpoint of PKIX standards.<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">It is also unfortunate that some browsers or applications seem not understand the PKIX standards well and I am afraid that their implementations of certificate
path validation algorithm might not be robust enough. The bad understanding about the PKIX standards might be revealed in browsers’ root certificate programs or policies. For example, in Microsoft Root Certificate Program, it is required that ‘CAs must generate
a new key and apply a new subject name when generating a new root certificate prior to distribution by Microsoft.’ The reason is ‘reuse of private keys or subject names in subsequent root certificates by the same CA may result in random certificate chaining
issues.’ According this requirement, Microsoft ask every Root CA to change their Distinguished Name (DN) each time they perform key rollover. Honestly, this is definitely wrong from the viewpoint of the PKX standards or even from the viewpoint of the X.500
international standards. In RFC 5280, self-issued certificates are clearly defined and the philosophy behind is that a CA would maintain its DN unchanged once it is named. Also in the PKIX standards (and in X.509 standards too), there are Issuer Key Identifier
and Subject Key Identifier extension fields defined for handling the situations where certificates might be issued by different generation of CA private keys but with the same CA DN. It is obvious that the implementation of certificate path validation algorithm
is not compliant to the PKIX standards. No wonder why IIS cannot properly handle self-issued certificates which is created when a Root CA follow the key rollover procedures and do not change its DN. We have file a bug report to Microsoft several months ago.
However, it seems that until now Microsoft still does not think it is a bug in IIS if it cannot correctly distinguish self-issued certificates from self-signed certificates.<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">Speaking of DN, the philosophy behind the X.500 international standards is that the Distinguished Name should be officially assigned by a naming authority. Once
the DN of an entity (including CAs) is assigned, it should not be changed unless its identity is changed (e.g., its affiliation is changed). Especially for a government CA, its DN might be assigned by an official naming authority and be published in the CP/CPS
or other official documents. In this situation, the CA’s DN is really not easy to changed and should not be changed. In this forum, folks tried to define more and more strict rules for end-entities’ Distinguished Names but it seems no one care about CAs changing
their DN frequently.<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">It is unfortunate that ‘CA has to change its DN whenever performing its key rollover’ is now considered the correct practice. On the contrary, we make our efforts
to follow the PKIX standards but sadly to be considered ‘the deployment path chosen is one that does not work nor has ever worked well with applications’ in this forum. We were here to argue what is right thing to do for key rollover regarding to the PKIX
standards, but unfortunately we got no backup from anyone. It is sad that CA vendors seems also do not care about what the standards says. Most CAs simply chose to change its DN whenever performing their key rollovers because browsers’ program request them
to do. I feel that CA vendors in this forum seldom spoke together to request browsers or applications to change their requirements or implementations even they were wrong.<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">Wen-Cheng Wang<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""> Ryan Sleevi [<a href="mailto:sleevi@google.com">mailto:sleevi@google.com</a>]
<br>
<b>Sent:</b> Monday, June 22, 2015 1:24 AM<br>
<b>To:</b> </span><span style="font-size:10.0pt">陳立群</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""><br>
<b>Cc:</b> </span><span style="font-size:10.0pt">江彬榮</span><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"">;
</span><span style="font-size:10.0pt">王文正</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Tahoma","sans-serif""><br>
<b>Subject:</b> Re: Introduce Chunghwa Telecom's representative to join 35th F2F meeting in Zurich<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">As indicated during the Cupertino F2F, we already support AIA on the majority of platforms (excluding Android). However, AIA does not and cannot resolve your issue, which has nothing to do with AIA but with how you've
configured your certificate hierarchy.<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">I indicated solutions during the Cupertino F2F, but since there may have been communication issues, I do want to stress that we do not view this as a bug in Chrome at present and have no plans to change any behaviours
that would allow this root to work. We strongly want to encourage Chunghwa Telecom to reconsider their approach to PKI, because the deployment path chosen is one that does not work nor has ever worked well with applications.<o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<div>
<p class="MsoNormal"><span lang="EN-US">On Sat, Jun 20, 2015 at 8:52 PM, </span>陳立群<span lang="EN-US"> <<a href="mailto:realsky@cht.com.tw" target="_blank">realsky@cht.com.tw</a>> wrote:<o:p></o:p></span></p>
<div>
<div>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US">Dear Ryan,<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> We have met in CA/Browser Forum 34th F2F meeting. My colleague Dr. Pin-Jung Chiang will join 35th F2F meeting. You can see Dr. Pin-Jung Chiang</span>’<span lang="EN-US">s
photo as attached file (Pin-Jung Chiang2015.jpg). <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> Besides, one of the WebTrust for CA auditor of our commercial CAs, Chen-Chung Hsiung of SunRise CPAs' Firm (DFK INTERNATIONAL) will join 35th F2F meeting.<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-indent:18.0pt">
<span lang="EN-US">Microsoft has not yet solve the IIS bug of roll over certificate that Apache server does not has as my presentation in March. We raise a premium support from Microsoft in March. IIS falsely treated GRCA</span>’<span lang="EN-US">s Self-Issued
certificate (new with old) as a Self-Signed certificate, because it has the same issuer and subject name. So Chrome in Mac or Linux, Firefox or Android will
<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US" style="color:#141823">not receive entire certificate chains from our government site using IIS. Microsoft Taiwan</span><span style="color:#141823">’<span lang="EN-US">s
staff said they were still reviewing their code. </span></span><span lang="EN-US" style="color:red"> I wonder Google Chrome will support AIA in the future.</span><span lang="EN-US"><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;text-indent:6.0pt">
<span lang="EN-US"> Wish you have a nice trip and meeting in Zurich. <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US">Sincerely Yours,
<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> <o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US">
</span><span lang="NO-BOK" style="color:#1F497D"> </span><span lang="EN-US">Li-Chun CHEN<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> Engineer<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> CISSP, CISA, CISM, PMP,<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> Information & Communication Security Dept.<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> Data Communication Business Group<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> Chunghwa Telecom Co. Ltd.<o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US">
<a href="mailto:realsky@cht.com.tw" target="_blank"><span style="color:windowtext;text-decoration:none">realsky@cht.com.tw</span></a><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US">
<a href="tel:%2B886-2-2344-4820%234025" target="_blank">+886-2-2344-4820#4025</a><o:p></o:p></span></p>
<p class="MsoNormal" style="mso-margin-top-alt:auto;mso-margin-bottom-alt:auto"><span lang="EN-US"> <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">,</span>非指定之收件者<span lang="EN-US">,</span>請勿蒐集、處理或利用本信件內容<span lang="EN-US">,</span>並請銷毀此信件<span lang="EN-US">.
</span>如為指定收件者<span lang="EN-US">,</span>應確實保護郵件中本公司之營業機密及個人資料<span lang="EN-US">,</span>不得任意傳佈或揭露<span lang="EN-US">,</span>並應自行確認本郵件之附檔與超連結之安全性<span lang="EN-US">,</span>以共同善盡資訊安全與個資保護責任<span lang="EN-US">. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US">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.<o:p></o:p></span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span lang="EN-US"><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"><o:p> </o:p></span></p>
</div>
</div>
</body>
</html>