Confirmed users, Administrators
5,526
edits
SecurityEngineering/mozpkix-testing: Difference between revisions
SecurityEngineering/mozpkix-testing (view source)
Revision as of 22:32, 22 April 2015
, 22 April 2015→Things for CAs to Fix
| Line 105: | Line 105: | ||
# OCSP responses for subscriber certificates must have a maximum expiration time of ten days. BR #13.2.2: "For the status of Subscriber Certificates: ... The CA SHALL update information provided via an Online Certificate Status Protocol at least every four days. OCSP responses from this service MUST have a maximum expiration time of ten days." | # OCSP responses for subscriber certificates must have a maximum expiration time of ten days. BR #13.2.2: "For the status of Subscriber Certificates: ... The CA SHALL update information provided via an Online Certificate Status Protocol at least every four days. OCSP responses from this service MUST have a maximum expiration time of ten days." | ||
#* Related Bugs: {{Bug|1025625}}, {{Bug|997509}} | #* Related Bugs: {{Bug|1025625}}, {{Bug|997509}} | ||
# All times in all certificates must be encoded in a way that conforms to the stricter requirements in RFC 5280. In particular, the timezone must always be specified as "Z" (Zulu/GMT). | |||
#* Related Bugs: {{Bug|1152515}} | |||
# When signing OCSP responses with a delegated OCSP response signing certificate, ensure that the delegated OCSP response signing certificate will not expire before the OCSP response expires. Otherwise, when doing OCSP stapling, some servers will cache the OCSP response past the point where the delegated response signing certificate expires, and then Firefox will reject the connection. | # When signing OCSP responses with a delegated OCSP response signing certificate, ensure that the delegated OCSP response signing certificate will not expire before the OCSP response expires. Otherwise, when doing OCSP stapling, some servers will cache the OCSP response past the point where the delegated response signing certificate expires, and then Firefox will reject the connection. | ||
#* Related Bugs: {{Bug|1046223}} | #* Related Bugs: {{Bug|1046223}} | ||
# RSA end-entity certificates that have a KeyUsage extension should include keyEncipherment in the KeyUsage extension if the subscriber intends for the certificate to be used for RSA key exchange in TLS. In other words, include keyEncipherment in RSA certificates--but not ECDSA certificates--unless the subscriber asks for it not to be included. This way, Firefox can start enforcing the correct KeyUsage. | |||
#* Related Bugs: {{Bug|970760}} | |||
# Include the subjectAltName extension with appropriate dNSName/iPAddress entries in all certificates. Hopefully soon Firefox will be able to stop falling back on the subject CN when there are no dNSName/iPAddress SAN entries. | |||
#* Related Bugs: {{Bug|1143085}}, {{Bug|1136616}}, {{Bug|1148766}} | |||
# Do not use any string types other than PrintableString and UTF8String in DirectoryString components of names. In particular, RFC 5280 says "TeletexString, BMPString, and UniversalString are included for backward compatibility, and SHOULD NOT be used for certificates for new subjects." Hopefully we will stop accepting certificates that use those obsolete encodings soon. | |||
#* Related Bugs: {{Bug|1089104}} | |||
# Use the same encoding for name constraints as subject alternative names. | |||
#* Related Bugs: {{Bug|1150114}} | |||
= Future Considerations = | = Future Considerations = | ||