[cabfpub] A conflict about EKU with PKIX

[Peter Bowen]

> On Mar 19, 2017, at 9:57 AM, 王文正 via Public <public at cabforum.org> wrote:
> 
> On Mar 7, 2017 at 12:46 AM, Ryan Sleevi via Public <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.

I am one of the many who has raised the topic, and there has been strong consensus from both IETF and ITU-T + ISO/IEC that the inclusion of an id-ce-extKeyUsage extension in a Certificate (whether CA-certificate or end-entity certificate) constrains the usage of the public key in the certificate, not the usage of public keys certificated by the CA named in the certificate.  This runs contrary to the usage of the id-ce-extKeyUsage extension in Microsoft, OpenSSL, and Mozilla NSS, and many other certificate validation libraries.  

Microsoft’s requirement is limited in scope to only roots that are trusted for both id-kp-serverAuth and id-kp-codeSigning: "Rollover root certificates, or certificates which are intended to replace previously enrolled but expired certificates, will not be accepted if they combine server authentication with code signing uses unless the uses are separated by application of Extended Key Uses (“EKU”s) at the intermediate CA certificate level that are reflected in the whole certificate chain.”

This requirement allows PKIs that do not use EKUs in CA-certificates to simply not request either id-kp-serverAuth or id-kp-codeSigning and comply with the requirements.

On the other hand the Google requirements mandate EKU in CA-certificates; this makes it impossible to simultaneously comply with the Google S/MIME requirements and any requirement that requires following PKIX/X.509.  I would hope that Google will consider changing their requirements to make the EKU in CA-certificate optional.

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

I agree with Wen-Cheng here.  It should be possible for a natural person or legal person to sign an email (or to be the intended recipient of an email).  This does mean that email clients my not be able to match the email address to the asserted identity, but this does not seem like nearly as large of a problem for mail as it does for the web.  Notably web browsing is a “pull” operation while email tends to be a “push” operation.  The recipient of email generally want to know who sent it, where “who” could be a person, a legal entity, or an email address.  In this scenario, it does make sense to support signing an email with a “general purpose” certificate that does not have specific EKU for SMIME.

Thanks,
Peter