On 8/24/15 10:12 AM, Brian Smith wrote:
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?
There is no default. I plan to hold a separate discussion for each item
in the https://wiki.mozilla.org/CA:CertPolicyUpdates#To_Be_Discussed
list. If we decide not to make a corresponding change, I will note that,
and we will move on.
I added separate sub-sections to make this more clear; see
https://wiki.mozilla.org/CA:CertPolicyUpdates#Will_NOT_Do
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
I added these suggestions -- see items 4 through 8 of
https://wiki.mozilla.org/CA:CertPolicyUpdates#To_Be_Discussed
Thanks,
Kathleen
_______________________________________________
dev-security-policy mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-security-policy
