[cabfpub] A conflict about EKU with PKIX

[Ryan Sleevi]

On Mon, Mar 6, 2017 at 8:26 AM, 陳立群 via Public <public at cabforum.org> wrote:

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

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.

https://www.ietf.org/mail-archive/web/pkix/current/msg27104.html
https://www.ietf.org/mail-archive/web/pkix/current/msg32409.html
https://www.ietf.org/mail-archive/web/pkix/current/msg33507.html


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.

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.

The logical consequence of this is that the anyEKU generally SHOULD NOT
appear in end-entity certificates.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170306/758cf1dd/attachment-0003.html>