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

[Jeremy Rowley]

One other thought is that a lot of groups use NSS as their basis for a trust store.  Impairing all the communities relying on that trust store might negatively impact the usefulness of NSS, meaning the issue is not as simple as using a single CA for multiple purposes v. creating forum rules.

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Thursday, November 13, 2014 2:07 PM
To: Moudrick M. Dadashov
Cc: Jeremy Rowley; CABFPub
Subject: Re: [cabfpub] (Eventually) requiring id-kpServerAuth for all certs in the chain?

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: https://cabforum.org/pipermail/public/attachments/20141113/83fc708e/attachment.html