On Fri, Mar 14, 2014 at 4:05 AM, Gervase Markham <[email protected]> wrote:
> On 13/03/14 19:20, Rick Andrews wrote: > > Is it because Mozilla intends to build CRLs sets in the future? > > Yes. > I always thought that the CRL requirement was in there because long of go we expected that we'd eventually start fetching CRLs at some point, and then it was left in there due to inertia, mostly. Keep in mind that S/MIME and TLS have different requirements. OCSP is a significant private issue for both. We can resolve that for TLS by switching to OCSP stapling. But, there's no good, practical stapling solution for S/MIME (S/MIME can in theory do stapling, but nobody does). It may be that we need to have separate requirements for S/MIME and TLS. I think it will make sense to revise the CRL requirement in the future, after we've figured out how we're going to build the revocation lists, and after we've figured out Must-Staple, and after we've figured out the issue in the preceding paragraph. If we don't end up using CRLs for building the revocation list then CRLs could very well be useless. Also, nobody has proposed a plan for using CRLs to build the revocation list, though Google does do that. Practically speaking, I'd argue strongly against any inclusions of CAs that don't support OCSP into our root store and/or EV programs. I wouldn't argue, at this time, against any CAs that don't do CRLs, but that could change. Cheers, Brian _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
