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

[Moudrick M. Dadashov]

Ok, sounds like what you are offering perfectly works for ETSI TS 102 
042 audited CAs - all SSL capable intermediates pass audit so nobody 
cares what their EKUs were, right. If this is what you mean, I'm fine 
with it.

Thanks,
M.D.

On 11/13/2014 11:06 PM, Ryan Sleevi wrote:
> 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 
> <mailto: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
>>     <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: <http://lists.cabforum.org/pipermail/public/attachments/20141113/1a8f58cc/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/1a8f58cc/attachment-0001.p7s>