Confirmed users, Administrators
5,526
edits
SecurityEngineering/mozpkix-testing: Difference between revisions
SecurityEngineering/mozpkix-testing (view source)
Revision as of 15:47, 29 April 2014
, 29 April 2014→Future Considerations
| Line 102: | Line 102: | ||
== Future Considerations == | == Future Considerations == | ||
While testing mozilla::pkix, we noticed the following things that we would like to consider. | While testing mozilla::pkix, we noticed the following things that we would like to consider. | ||
# In mozilla::pkix we won't accept any OCSP responses that are more than 10 days old, even for intermediate certificates. So EV treatment will not be given when an OCSP response is older than 10 days. In the [https://cabforum.org/baseline-requirements-documents/ BRs], the statement: "OCSP responses from this service MUST have a maximum expiration time of ten days."needs to be added to the Subordinate CA Certificates section. If a CA with an intermediate OCSP nextUpdate six months in the future actually revokes that intermediate today because an attacker got its private key, then an attacker could still MitM users for 6 months from today. We need to require intermediate OCSP nextUpdate values to be 10 days from thisUpdate or less. | # In mozilla::pkix we won't accept any OCSP responses that are more than 10 days old, even for intermediate certificates. So EV treatment will not be given when an OCSP response is older than 10 days. In the [https://cabforum.org/baseline-requirements-documents/ BRs], the statement: "OCSP responses from this service MUST have a maximum expiration time of ten days." needs to be added to the Subordinate CA Certificates section. If a CA with an intermediate OCSP nextUpdate six months in the future actually revokes that intermediate today because an attacker got its private key, then an attacker could still MitM users for 6 months from today. We need to require intermediate OCSP nextUpdate values to be 10 days from thisUpdate or less. | ||
#* Related Bugs: {{Bug|991815#c4}} | #* Related Bugs: {{Bug|991815#c4}} | ||
# EV treatment should not be given when the end-entity cert is signed directly by the root cert. The [https://cabforum.org/extended-validation/ EV Guidelines] say: "Root CA Private Keys MUST NOT be used to sign EV Certificates." We should programmatically enforce this. | # EV treatment should not be given when the end-entity cert is signed directly by the root cert. The [https://cabforum.org/extended-validation/ EV Guidelines] say: "Root CA Private Keys MUST NOT be used to sign EV Certificates." We should programmatically enforce this. | ||