[cabfpub] (Eventually) requiring id-kpServerAuth for all certs in the chain?
Rick_Andrews at symantec.com
Wed Nov 12 10:50:26 MST 2014
Brian, that's correct. But it would still be a lot of work for us.
From: Brian Smith [mailto:brian at briansmith.org]
Sent: Tuesday, November 11, 2014 11:24 PM
To: Rick Andrews
Cc: Gervase Markham; CABFPub
Subject: Re: [cabfpub] (Eventually) requiring id-kpServerAuth for all certs in the chain?
On Thu, Nov 6, 2014 at 1:17 PM, Rick Andrews <Rick_Andrews at symantec.com> wrote:
> Gerv, off-hand I'd say about half of the non-technically-constrained intermediates we've issued from our publicly trusted roots are not BR-covered. They sign code signing, timestamping, and client auth certs. But none of them (and none of our SSL intermediates) contain an EKU. If we'd have to re-issue SSL intermediates to add serverAuth EKU and non-SSL intermediates to add EKU with some other value, then we'd have to reissue all our intermediates. And we wouldn't be very excited about that.
Rick, you only have to re-issue (and revoke the old version of) non-SSL intermediates, not SSL intermediates, because the lack of an EKU implies anyExtendedKeyUsage which implies id-kp-serverAuth.
More information about the Public