<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Mar 6, 2017 at 8:26 AM, 陳立群 via Public <span dir="ltr"><<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Regarding the use of Extended Key Usage (EKU) extension, we found there is a conflict between Microsoft Root Certificate Program /Google S/MIME Certificate Profile and the original X.509 standard as well as the PKIX profile (RFC 5280).<br>
<br>
According to RFC5280, if a certificate contains EKU extension, then it must only be used for one of the purpose indicated. If a CA does not wish to restrict usages of the key, what the CA can do is to include the special KeyPurposeId “anyEKU” in the EKU extension.<br>
<br>
However, according to the section of 4.A.18 in Microsoft Root Certificate Program and the requirement for EKU extension of EE certificate in Google S/MIME Certificate Profiles, if a CA wishes to meet their requirements, then the EE certificate must contain the EKU and the KeyPurposeId “anyExtendedKeyUsage” must not present.<br>
<br>
For SSL certificates and Code Signing certificates, they are usually dedicated for specific usage. Therefore, it usually will not cause problem if restricting their EKU extensions to not containing the KeyPurposeId “anyExtendedKeyUsage”.<br>
<br>
However, for general-purposed EE certificates, they are usually can be used for S/MIME, document signing, client authentication, SSO, etc. If a CA follows the requirements of Microsoft and Google, then certificates used for S/MIME will only contain a key usage extension “digitalSignature” and an EKU extension with KeyPurposeId “emailProtection” but without “anyExtendedKeyUsage”. That means those certificates cannot be used for other general purposes anymore. Recently, some of our users complained about this issue because their PKIX-compliant certificate processing software refused to accept their S/MIME certificates to be used for other general purposes.<br>
<br>
To resolve this conflict, we think there might be two options:<br>
<br>
Option 1:<br>
Certificates should be divided into two kinds. One is for certificates used for some specific use such as TLS/SSL, code sign, etc. These certificates must contain an EKU extension and the KeyPurposeId “anyExtendedKeyUsage” must be not present. The other is for certificates used for non-specific use such as client authentication, SSO, S/MIME, document signing, etc. These certificates are allowed to contain the KeyPurposeId “anyExtendedKeyUsage” in the EKU extension so that they can be used for general usages (e.g., digital signature and encryption/decryption) at the same time.<br>
<br>
Option 2:<br>
For certificate-using software such as browsers or email software, we recommend to use Certificate Policy OIDs to check whether the CA is authorized to issue some kind of EE certificate (such as SSL/TLS, code signing, S/MIME, etc.) instead of using EKU. That means the CA certificate and EE certificate must both contain some specific Certificate Policy OIDs. Root Certificate Programs and Certificate profiles can restrict that some Certificate Policy OIDs cannot co-exist in the same certificate. For example, SSL/TLS OIDs cannot co-exist with code-signing OID. Currently, CA/Browser forum has already defined EV SSL OID, OV SSL OID, DV SSL OID, IV SSL OID, and EV Code Signing OID. We simply need to further define Certificate Policy OIDs for S/MIME, non-EV Code Signing, etc.<br>
<br>
For example, According to RFC5280, the certificates must only be used for Secure Email. That is to say, it will restrict usages of key and will not allow the key to be used to other applications such as digital signature in general, document signing, etc. However, for general relying parties, they wish EE certificates can be used not only for Secure Email but also for other purposes (e.g., client authentication and document signing) in fact. If a CA wishes to satisfy their needs, then the certificate shall contain an EKU extension including the KeyPurposeId “emailProtection”and “anyExtendedKeyUsage” simultaneously based on RFC 5280. It will violate the rules defined in Microsoft Root Certificate Program and Google S/MIME Certificate Profiles.<br>
<br>
Thus, we suggest that Microsoft divide the section of 4.A.18 in Microsoft Root Certificate Program into two parts. One is for certificates used for some specific use such as TLS/SSL, code sign, etc. These certificates must contain an EKU extension and the KeyPurposeId “anyExtendedKeyUsage” must be not present. The other is for certificates used for non-specific use such as client authentication, S/MIME, etc. We suggest that certificates shall contain an EKU extension and the KeyPurposeId “anyExtendedKeyUsage” must be present to allow the certificates to be used for general usages (e.g., digital signature and encryption/decryption) at the same time.<br>
<br>
For Google, we suggest that the certificate used for S/MIME shall contain an EKU extension and the KeyPurposeId “anyExtendedKeyUsage” must be present as describe above. <br>
<br>
<br>
     Li-Chun Chen<br>
     Chunghwa Telecom Co., Ltd.<br></blockquote><div><br></div><div>For those new to the discussion, this seems to have cropped up every few years in the IETF - Here's a selection of messages going back over a decade on this topic.</div><div><br></div><div><a href="https://www.ietf.org/mail-archive/web/pkix/current/msg27104.html">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">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">https://www.ietf.org/mail-archive/web/pkix/current/msg33507.html</a></div></div><div><br></div><div><br></div><div>With respect to Google's program requirements, the current operating thought is that certificates should be dedicated for the appropriate purpose, and that reusing the same certificate across different application spaces - such as document signing versus S/MIME - is not a recommended practice.</div><div><br></div><div>That said, should a CA wish to apply such logic to the certificates they issue, they MUST issue from an intermediate that explicitly lists the purposes for which it is authorized. As Li-Chun notes, this means that such intermediates used to issue these end-entity certificates MUST note all the purposes for which the certificate is intended.</div><div><br></div><div>The logical consequence of this is that the anyEKU generally SHOULD NOT appear in end-entity certificates.</div></div></div></div>