Confirmed users, Administrators
5,526
edits
CA/Root Store Policy Archive: Difference between revisions
m
→Consider for Version 2.3
(Add numbering) |
|||
| Line 83: | Line 83: | ||
#* Remove reference to SHA-512 -- {{Bug|1129083}} | #* Remove reference to SHA-512 -- {{Bug|1129083}} | ||
#* Remove reference to P-512 -- {{Bug|1129077}} | #* Remove reference to P-512 -- {{Bug|1129077}} | ||
# Make it clearer that producing [https://mozillacaprogram.secure.force.com/Communications/CommunicationActionOptionResponse?CommunicationId=a04o000000M89RCAAZ&Question=ACTION%20%234:%20Workarounds%20were%20implemented 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 [[SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix|Mozilla's list of Things for CAs to Fix]] | |||
# When an OCSP response signing certificate expires before the OCSP responses signed by the certificate expire, multiple websites break, particularly sites that use OCSP stapling. 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. | |||
# 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. | |||
# 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. | |||
# Make it very clear that a CA with a root certificate included in Mozilla's program is ultimately responsible for every certificate issued that directly or indirectly chains up to the included certificate. If a CA's subcontractors (RAs, subCAs, etc.) have their own practice documentation, it must be inclusive of the CA's practices. | # Make it very clear that a CA with a root certificate included in Mozilla's program is ultimately responsible for every certificate issued that directly or indirectly chains up to the included certificate. If a CA's subcontractors (RAs, subCAs, etc.) have their own practice documentation, it must be inclusive of the CA's practices. | ||
#* The subcontractors may have their own practices '''in addition''' to the practices that the CA's CP/CPS impose on them. And the CA's CP/CPS must impose practices that are in line with Mozilla's CA Certificate Policies and CA/Browser Forums Baseline Requirements (depending on the types of certs the function '''is capable''' of issuing). | #* The subcontractors may have their own practices '''in addition''' to the practices that the CA's CP/CPS impose on them. And the CA's CP/CPS must impose practices that are in line with Mozilla's CA Certificate Policies and CA/Browser Forums Baseline Requirements (depending on the types of certs the function '''is capable''' of issuing). | ||