[cabfpub] A conflict about EKU with PKIX

[陳立群]

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).

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.

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. 

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”.

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.

To resolve this conflict, we think there might be two options:

Option 1: 
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.

Option 2:
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.

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.

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.

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. 


     Li-Chun Chen
     Chunghwa Telecom Co., Ltd.



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