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

[Moudrick M. Dadashov]

Thanks, Ryan, I see the point.
Is there a non extreme approach here that preserves those valuable 
libraries and doesn't kill those intermediates that have been in use for 
years? Could it a transitional time frame after which we have a single, 
widely supported solution?

Thanks,
M.D.


On 11/13/2014 10:53 PM, Ryan Sleevi wrote:
>
> On Thu, Nov 13, 2014 at 12:51 PM, Moudrick M. Dadashov <md at ssc.lt 
> <mailto:md at ssc.lt>> wrote:
>
>     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.
>
>
> Because it's widely implemented in a variety of libraries and provides 
> immediate security benefits for clients, and immediate clarifications 
> for CAs about in scope vs out of scope, and doesn't conflict with any 
> of the language in RFC 5280 - which, while was accurate at the time it 
> was written ("In general, this doesn't appear in CA certs"), is NOT a 
> prohibition against it, just an observation.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: https://cabforum.org/pipermail/public/attachments/20141113/2aee73ba/attachment-0001.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 : https://cabforum.org/pipermail/public/attachments/20141113/2aee73ba/attachment-0001.bin