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

[Jeremy Rowley]

That page was updated in October 2014. I don’t think we can imply knowledge to all communities who might have existed before then.

I also don’t think the audit itself is a concern.  However, the requirements on key generation under Section 17.7 might not have been followed, the intermediate might not have CRLs or OCSP (depending on the community), and auditor qualifications might be bigger problems.

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


On Thu, Nov 13, 2014 at 1:13 PM, Jeremy Rowley <jeremy.rowley at digicert.com<mailto:jeremy.rowley at digicert.com>> wrote:
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.

Can you please clarify what you mean by "impairing"? If you're using the Mozilla Trust Store to make decisions outside of the Mozilla purview. That is, it has three trust bits, only one of which has an audit requirement - namely, the Website bit requires BR AND Mozilla Policy compliance. The Mozilla Policy compliance ALREADY requires (effectively) that all certificates (transitively) be BR compliant. So if there is an incompatibility in schemes, these users are already "impaired"

And Mozilla's made it clear the risks these groups run if they're using the NSS trust store outside of NSS - https://wiki.mozilla.org/CA:FAQ#Can_I_use_Mozilla.27s_set_of_CA_certificates.3F - so I don't think that's a consideration the Forum should engage in, as Mozilla's already explicitly disclaimed it.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20141113/0a845cd4/attachment-0003.html>