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

[Ryan Sleevi]

Jeremy,

that language is hardly normative, nor are there normative restrictions on
it, nor would it adversely affect the algorithm of RFC 5280 Section 6 (and
indeed, if someone was enforcing that CAs not have the EKU, they'd be
violating Section 6.1 para3)

While the algorithm could be extended to include checks for
> conformance to the profiles in Sections 4 and 5, this profile
> RECOMMENDS against including such checks.


So I'm not sure I fully understand your concern.


On Thu, Nov 13, 2014 at 12:40 PM, Jeremy.Rowley <jeremy.rowley at digicert.com>
wrote:

>  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> 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 listPublic at cabforum.orghttps://cabforum.org/mailman/listinfo/public
>
>
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141113/f32e91b1/attachment.html