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

[Moudrick M. Dadashov]

It certainly does. I understand folks looking for a programmatic 
discovery of cert types, but still curious why EKU is more appropriate 
for this than any other predefined field that raises no conflict with 
standards.

Thanks,
M.D.


On 11/13/2014 10:40 PM, Jeremy.Rowley 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 <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
>
>
>
> _______________________________________________
> 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/fd8aa2e6/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3653 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.cabforum.org/pipermail/public/attachments/20141113/fd8aa2e6/attachment-0001.p7s>