[cabfpub] Suggestion for AIA support and problem regarding key rollover with self-issued certificates

[王文正]

Folks,

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.

Wen-Cheng Wang
Chunghwa Telecom Co., Ltd

From: 王文正
Sent: Monday, June 22, 2015 9:21 PM
To: 'Ryan Sleevi'; 陳立群
Cc: 江彬榮; 熊振中
Subject: RE: Introduce Chunghwa Telecom's representative to join 35th F2F meeting in Zurich

Ryan,

Thank you for your suggestions.

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.

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.

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.

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.

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.

Wen-Cheng Wang

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Monday, June 22, 2015 1:24 AM
To: 陳立群
Cc: 江彬榮; 熊振中; 王文正
Subject: Re: Introduce Chunghwa Telecom's representative to join 35th F2F meeting in Zurich

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.

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.

On Sat, Jun 20, 2015 at 8:52 PM, 陳立群 <realsky at cht.com.tw<mailto:realsky at cht.com.tw>> wrote:
Dear Ryan,

    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’s photo as attached file (Pin-Jung Chiang2015.jpg).

   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.

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’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
not receive entire certificate chains from our government site using IIS.  Microsoft Taiwan’s staff said they were still reviewing their code.   I wonder Google Chrome will support AIA in the future.
  Wish you have a nice trip and meeting in Zurich.

Sincerely Yours,

                   Li-Chun CHEN
                    Engineer
                    CISSP, CISA, CISM, PMP,
                    Information & Communication Security Dept.
                    Data Communication Business Group
                    Chunghwa Telecom Co. Ltd.
                    realsky at cht.com.tw<mailto:realsky at cht.com.tw>
                    +886-2-2344-4820#4025<tel:%2B886-2-2344-4820%234025>


本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件. 如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任.
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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20150623/39fcb507/attachment-0002.html>