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

[Ryan Sleevi]

That's the fundamental difference between Gerv's proposal and mine.

My proposal is that all of the certs capable must be audited, with capable
be defined as either the presence of (id-kp-serverAuth, anyEKU) in the
intermediate OR the absence of ALL EKUs in the intermediate. If it's
capable, it MUST be audited to the BRs.

If you thus wish to exclude such an intermediate from the scope of a BR
audit (for example, because you intend to use it with some other scheme),
then you need to change your hierarchy. However, if you're not such a CA
running multiple schemes, then no action is required, and all the
intermediates stay useful.

Then we can independently discuss any changes, but it solves the near-term
ambiguity.

Gerv's proposal requires more drastic actions, and thus will naturally take
quite some time to phase in.

On Thu, Nov 13, 2014 at 1:01 PM, Moudrick M. Dadashov <md at ssc.lt> wrote:

>  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> 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/91176085/attachment.html