Confirmed users, Administrators
5,526
edits
SecurityEngineering/mozpkix-testing: Difference between revisions
SecurityEngineering/mozpkix-testing (view source)
Revision as of 18:41, 21 September 2015
, 21 September 2015→Things for CAs to Fix
| (One intermediate revision by the same user not shown) | |||
| Line 101: | Line 101: | ||
# OCSP responders should not include a responseExtensions consisting of an empty SEQUENCE (e.g. A2 02 30 00 - see http://tools.ietf.org/html/rfc6960#section-4.2.1 under ResponseData for reference). [http://www.ietf.org/rfc/rfc3280.txt RFC 3280] defines Extensions as SEQUENCE SIZE (1..MAX) OF Extension, so the empty SEQUENCE is not a valid encoding. Instead of using an empty SEQUENCE, the OCSP responder should just omit the responseExtensions in the ResponseData. | # OCSP responders should not include a responseExtensions consisting of an empty SEQUENCE (e.g. A2 02 30 00 - see http://tools.ietf.org/html/rfc6960#section-4.2.1 under ResponseData for reference). [http://www.ietf.org/rfc/rfc3280.txt RFC 3280] defines Extensions as SEQUENCE SIZE (1..MAX) OF Extension, so the empty SEQUENCE is not a valid encoding. Instead of using an empty SEQUENCE, the OCSP responder should just omit the responseExtensions in the ResponseData. | ||
#* Related Bugs: {{Bug|991898}}, {{Bug|997994}} | #* Related Bugs: {{Bug|991898}}, {{Bug|997994}} | ||
# 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). | # 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}} | #* Related Bugs: {{Bug|1152515#c15}}, {{Bug|1085238#c4}}, {{Bug|1019770}} | ||
#* Beginning in Firefox 33, mozilla::pkix enforces the requirement that the timezone always be specified as "Z". However, there may be some UX and certificate viewer cleanup needed to make this more clear, as per {{Bug|1152515#c15}} and {{Bug|1152515#c16}} | |||
# 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}} | ||