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

Jeremy.Rowley jeremy.rowley at digicert.com
Thu Nov 13 20:40:32 UTC 2014


Doesn't all this ignore 5280's recommendation that "In general, this 
extension will appear only in end entity certificates"? Ignoring this 
might put browsers at odds with other industry groups also using PKI.



On 11/5/2014 2:31 PM, Brian Smith wrote:
> Gerv,
>
> Please note that Ryan and I appear to be suggesting exactly the same 
> thing. And, note that what I'm suggesting here is exactly the same 
> argument I made for interpreting EKU in end-entity certificates 
> earlier this year or last year: a lack of EKU is equivalent to 
> "anyExtendedKeyUsage". This is what all (AFAICT) certificate 
> verification code does today.
>
> Gervase Markham <gerv at mozilla.org <mailto:gerv at mozilla.org>> wrote:
>
>     > However, I'm assuming that for the CAs for which the BRs apply, it is
>     > already the case that all or most of their intermediates conform
>     to the
>     > BRs.
>
>     I would hope so. But is it programmatically detectable that they
>     do? If
>     so, how? "Publicly audited" is not a determinable characteristic of an
>     intermediate.
>
>
> Your proposal has the same issue. In both proposals, just by looking 
> at the certificate chain, you can tell whether the intermediate is 
> required to conform to the BRs or not. The only difference is that the 
> way Ryan and I are suggesting already matches what Chrome (on Windows, 
> at lesat), IE, and Firefox are already doing, whereas you are 
> proposing that all browsers eventually (5-10 years from now?) be 
> changed to do something new, without any protection for users until then.
>
>     Also, your proposal 1) requires a re-issue of intermediates for all
>     private PKIs, right? Because they all need to have EKUs in them?
>
>
> If a CA certificate chains to a root for which the BRs apply, and that 
> sub-CA doesn't want to be held to the BRs (ostensibly because they 
> don't intend to issue SSL certificates), then they would need to have 
> their sub-CA cert re-issued (and the old one revoked) with an EKU 
> extension that does not include id-kp-serverAuth or 
> anyExtendedKeyUsage, unless their certificate already has such an EKU. 
> That is the only situation in which re-issuance would be necessary.
>
> If private CAs don't issue SSL certificates, then it would be a good 
> idea to replace their CA certificates with ones that contain an EKU 
> that doesn't have id-kp-serverAuth or anyExtendedKeyUsage, to follow 
> the principle of least privilege. But, they wouldn't be required to 
> make any change, because the BRs don't apply to them, assuming that 
> they don't chain to a trusted root. If they do chain to a trusted root 
> then they're not private and the above paragraph applies.
>
> Cheers,
> Brian
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20141113/35adaa4f/attachment-0003.html>


More information about the Public mailing list