<html dir="ltr">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=big5">
<style type="text/css" id="owaParaStyle"></style>
</head>
<body fpstyle="1" ocsi="0">
<div style="direction: ltr;font-family: Times New Roman;color: #000000;font-size: 12pt;">
<div style="font-family: Times New Roman; color: #000000; font-size: 16px">
<div>
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">On Mar 7, 2017 at 12:46 AM, <span style="font-family: Tahoma; font-size: small;">Ryan Sleevi</span> via Public
<span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:
<div>> For those new to the discussion, this seems to have cropped up every few years in the IETF - Here's a </div>
<div>> selection of messages going back over a decade on this topic.</div>
<div>> </div>
<div>> <a href="https://www.ietf.org/mail-archive/web/pkix/current/msg27104.html" target="_blank">https://www.ietf.org/mail-archive/web/pkix/current/msg27104.html</a><br>
</div>
<div>> <a href="https://www.ietf.org/mail-archive/web/pkix/current/msg32409.html" target="_blank">https://www.ietf.org/mail-archive/web/pkix/current/msg32409.html</a> </div>
<div>
<div>> <a href="https://www.ietf.org/mail-archive/web/pkix/current/msg33507.html" target="_blank">https://www.ietf.org/mail-archive/web/pkix/current/msg33507.html</a></div>
</div>
<div><br>
</div>
<div>These discussion threads in IETF PKIX WG clearly pointed out that "using EKUs as constraints in intermediate CA certificates" is a mistake. I hope this mistake would not be inherited into the Google's S/MIME profile.</div>
<div><br>
</div>
<div>If the purpose is to make sure only those EE certificates issued by those CAs which comply to some kinds of S/MIME certificate policies (or requirements), please consider to define an OID for S/MIME certificate policy and use Certificate Policy chaining
for that purpose.</div>
<div><br>
</div>
<div>> With respect to Google's program requirements, the current operating thought is that certificates </div>
<div>> should be dedicated for the appropriate purpose, and that reusing the same certificate across different </div>
<div>> application spaces - such as document signing versus S/MIME - is not a recommended practice.</div>
<div><br>
</div>
<div>There might already be billions of eID certificates issued by governments all over the world. I believe that in most eID programs, governments not only want their citizens can use eID certificates for general-purposed e-authentication, e-signature, and
encryption in e-government applications or e-commerce applications but also want to let their citizens can use eID certificates for S/MIME secure emails. If Google's S/MIME profile prohibits reusing the same certificate across the S.MIME usage and general-purposed
e-government or e-commerce usages, I am afraid it will reject billions of eID certificates from being used S/MIME secure emails.</div>
<div> </div>
<div>> That said, should a CA wish to apply such logic to the certificates they issue, they MUST issue from </div>
<div>> an intermediate that explicitly lists the purposes for which it is authorized. As Li-Chun notes, this </div>
<div>> means that such intermediates used to issue these end-entity certificates MUST note all the purposes </div>
<div>> for which the certificate is intended.</div>
<div>> </div>
<div>> The logical consequence of this is that the anyEKU generally SHOULD NOT appear in end-entity </div>
<div>> certificates.</div>
<div>
<div><br>
</div>
<div>In practice, it is not possible to enumerate all the purposes for which eID certificates is intended. If a government has ever defined a private EKU with its Key Purpose ID indicating that the certificates can be used in any kinds of e-government or e-commerce
applications in that jurisdiction or country, the private EKU will be in fact similar to the anyEKU.</div>
</div>
<div><br>
</div>
<div>Best Regards,</div>
<div>Wen-Cheng Wang</div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<B><BR><BR><font size="-1">本信件可能包含中華電信股份有限公司機密資訊,非指定之收件者,請勿蒐集、處理或利用本信件內容,並請銷毀此信件.
如為指定收件者,應確實保護郵件中本公司之營業機密及個人資料,不得任意傳佈或揭露,並應自行確認本郵件之附檔與超連結之安全性,以共同善盡資訊安全與個資保護責任.
<BR>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.</font></B>
</body>
</html>