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

Ryan Sleevi sleevi at google.com
Thu Nov 13 21:02:57 UTC 2014


If these groups are requiring that it MUST NOT appear in intermediates,
then they're defining a profile atop RFC 5280, right? So it's not that it's
an RFC 5280 issue, but a broader issue with whatever other specification.

If it were that some group required EE certs MUST be RSA 1024-bit, or MUST
use SHA-1, would we have the same concern? I recall some for the former
(ironically, in the payment industry, which is all sorts of depressing),
less so for the latter, but in either case, this seems to highlight a
fundamental issue with CAs trying to use the same root to be audited to
multiple standards - at some point, you must be prepared for the standards
to diverge.

There are plenty of ways to mitigate those risks (as has been discussed in
the past), but is it a Forum issue or a
CA-using-the-same-root-for-different-things issue?

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

>  I realize it's not normative and it's not really a concern for us - more
> of an observation that requiring an EKU in intermediates is opposite of the
> text in the RFC.  The issue is not that we'd break those other groups but
> that we'd force their intermediates to comply with the BRs, which might not
> be possible for some groups.
>
> Jeremy
>
>
> On 11/13/2014 1:45 PM, Ryan Sleevi wrote:
>
> 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: <http://lists.cabforum.org/pipermail/public/attachments/20141113/f500d26e/attachment-0003.html>


More information about the Public mailing list