On Mon, Aug 24, 2015 at 5:53 AM, Gervase Markham <[email protected]> wrote:
> On 20/08/15 19:12, Kathleen Wilson wrote: > > It's time to begin discussions about updating Mozilla's CA Certificate > > Policy. > > Great :-) > > > A list of the things to consider changing is here: > > https://wiki.mozilla.org/CA:CertPolicyUpdates#Consider_for_Version_2.3 > > How do you want to deal with this list? Is it "default-do" or > "default-don't-do"? That is, should I spend my time arguing for the > changes I would like to see, arguing against the changes I think are > bogus, or a combination of the two? > I also have this same question. > > Please review the list to let me know if there are any topics missing. > 1. Mozilla recently asked some CAs about their practices in issuing certificates that are syntactically invalid in various ways, and we got a lot of good responses [1]. I was struck by the responses like GlobalSign's that basically said, paraphrasing, "we intend to continue knowingly violate the baseline requirements by issuing syntactically invalid certificates." I think it would be good to make it clearer that producing syntactically valid certificates is **required**. In particular, I think that Mozilla should audit a CA's recently-issued certificates and automatically reject a CA's request for inclusion or membership renewal if there are a non-trivial number of certificates that have the problems mentioned in [2]. (Also, I have some new information about problematic practices to expand the list in [2], which I hope to share next week.) 2. Last week (or so), one of GlobalSign's OCSP response signing certificates expired before the OCSP responses signed by the certificate expired (IIUC), which caused problems for multiple websites, particularly ones that use OCSP stapling. Please make it a requirement that every OCSP response must have a nextUpdate field that is before or equal to the notAfter date of the certificate that signs it. This should be easy for CAs to comply with. 3. Please add a requirement that every OCSP response must have a nextUpdate field. This is required to ensure that OCSP stapling works *reliably* with all (at least most) server and client products. 4. Please add a requirement that the nextUpdate field must be no longer than 72 hours after the thisUpdate field, i.e. that OCSP responses expire within 3 days, for every certificate, for both end-entity certificates and CA certificates. 5. On the page you linked to, there are items about removing support for SHA-512-signed and P-521-signed certificates. Those were suggested by me previously. I would like to change my suggestion to just recommending that CAs avoid SHA-512 and P-521, especially in their CA certificates. Again, this is to ensure interoperability, as SHA-512 and (especially) P-521 are less well-supported than the other algorithms. (Note: On the page you linked to, P-521 is incorrectly spelled "P-512".) Thanks, Brian [1] https://mozillacaprogram.secure.force.com/Communications/CommunicationActionOptionResponse?CommunicationId=a04o000000M89RCAAZ&Question=ACTION%20%234:%20Workarounds%20were%20implemented [2] https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
