[cabfpub] A conflict about EKU with PKIX

[王文正]

On Mar 7, 2017 at 12:46 AM, Ryan Sleevi via Public <public at cabforum.org<mailto:public at cabforum.org>> wrote:
> 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

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.

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.

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

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.

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

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.

Best Regards,
Wen-Cheng Wang


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://cabforum.org/pipermail/public/attachments/20170319/d7ad6835/attachment-0001.html>