[cabfpub] (Eventually) requiring id-kpServerAuth for all certs in the chain?

[Bruce Morton]

Sorry, my error. Somehow I got Certificate Policy and EKU mixed up in my mind.

We do limit our intermediate CAs which issue SSL certificates to Server Auth and Client Auth.

Sorry for the confusion. I think I'll go home now. :-)

Bruce.

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Bruce Morton
Sent: Monday, November 03, 2014 3:55 PM
To: Gervase Markham; CABFPub
Subject: Re: [cabfpub] (Eventually) requiring id-kpServerAuth for all certs in the chain?

Hi Gerv,

I think it would be a good idea to understand the problems, get agreement that they need to be addressed, and agree on the solution(s).

To date, we have had no customer or third party support issues with using anyPolicy. Also, we have had no issues with our auditors to indicate which intermediate CAs issue SSL certificates and are subject to the BRs.

With third parties, we do restrict the intermediate CA certificates typically with Server Auth and Client Auth. Fortunately, there have been no issues with these configurations as well.

It would be great to get more input before making such a change. Personally, I like that the CA has some flexibility when using anyPolicy, although I never see us taking advantage of that flexibility.

Bruce.

-----Original Message-----
From: public-bounces at cabforum.org [mailto:public-bounces at cabforum.org] On Behalf Of Gervase Markham
Sent: Monday, November 03, 2014 2:46 PM
To: CABFPub
Subject: [cabfpub] (Eventually) requiring id-kpServerAuth for all certs in the chain?

Hi everyone,

I wonder if the BRs should say that all non-root certs in a chain issued for SSL server use, which were issued after <date>, should have EKU id-kpServerAuth in them. Date would be, say, six months from now.

This is primarily aimed at intermediates; EE certs all currently have this anyway. It would mean that, over time (years) as intermediates got replaced, we could eventually move to a position where it was entirely clear what certs were intended for Web PKI SSL use and what certs were not.

Currently, any intermediate in the world issued by a publicly-trusted root can issue for SSL, even those intermediates which are not intended for such use. This leads to numerous problems, including the question of whether such intermediates need to be covered by a BR audit. Once this change had filtered through, it would be clear - they would not be.

AIUI, EKU "chaining" (i.e. requiring an EKU to be present all the way up the chain) is not standard, but is implemented in NSS and elsewhere.

I know this is a thing which only pays off in the long term, but I still think it's worth it. Does this make any sense, or have I missed something obvious? :-)

Gerv
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public
_______________________________________________
Public mailing list
Public at cabforum.org
https://cabforum.org/mailman/listinfo/public