SecurityEngineering/mozpkix-testing: Difference between revisions

← Older edit

SecurityEngineering/mozpkix-testing (view source)

Revision as of 18:41, 21 September 2015

2,828 bytes added , 21 September 2015

m

→‎Things for CAs to Fix

Kathleen Wilson

Confirmed users, Administrators

5,526

edits

@@ Line 16: / Line 16: @@
 #* Download by selecting the .tar.bz2 (Linux), .dmg (Mac), or .exe (Windows) file.
 #* After downloading, extract and run this nightly browser, which will be called FirefoxNightly.
-# mozilla::pkix should be enabled by default. Ensure that it is by doing the following:
+# In Firefox 33 and later, mozilla::pkix is enabled by default, and there is no longer an about:config option to disable it.
+# In Firefox 31 and Firefox 32 mozilla::pkix is enabled by default, and there is an about:config option that can be used to disable and enable it. In Firefox 31 and Firefox 32 you can ensure that mozilla::pkix is enabled by doing the following:
 #* Open [http://kb.mozillazine.org/About:config about:config] in Firefox
 #* Locate the preference "security.use_mozillapkix_verification"
@@ Line 25: / Line 26: @@
 # Browse to various websites with known valid and expired/revoked/etc SSL certificates.
 #* Note to CAs: Be sure to check EV status, and check chains through all currently-used intermediate certs.
-# If you don't get the expected result, then try again without using mozilla::pkix to see if the unexpected result is actually due to mozilla::pkix.
+# If you don't get the expected result, then in Firefox 31 and Firefox 32 you can try again without using mozilla::pkix to see if the unexpected result is actually due to mozilla::pkix.
 #* In [http://kb.mozillazine.org/About:config about:config] toggle "security.use_mozillapkix_verification" to false
 #** Or switch to a previously released version of Firefox
@@ Line 91: / Line 92: @@
 #* Intermediate certificates are not required to have an EKU, but if a new intermediate certificate does have an EKU and the intermediate will be used for SSL, then it must have the id-kp-serverAuth EKU. See sections #8, 9, and 10 of [http://www.mozilla.org/about/governance/policies/security-group/certs/policy/inclusion/ Mozilla's CA Certificate Inclusion Policy].
 #* Related Bugs: {{Bug|982292}}, {{Bug|982932}}, {{Bug|982936}}
-# Default values in a SEQUENCE must not be explicitly encoded. We found end-entity certificates that have the value cA:false explicitly encoded.
+# Default values in a SEQUENCE must not be explicitly encoded.
-#* 11.5 of X.690 - "The encoding of a set value or sequence value shall not include an encoding for any component value which is equal to its default value."
+#* [http://www.itu.int/ITU-T/studygroups/com17/languages/X.690-0207.pdf ITU-T X.690] section 11.5: "The encoding of a set value or sequence value shall not include an encoding for any component value which is equal to its default value."
+#* Note: We encountered certificates with a basicConstraints extension that explicitly encoded the default value cA:false. The solution that we recommend is to not include the basicConstraints extension in end-entity certificates.
 #* Related Bugs: {{Bug|988633}}, {{Bug|989516}}, {{Bug|989518}}
 # Basic constraints: pathLenConstraint must not be included if cA is false
@@ Line 99: / 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.
 #* Related Bugs: {{Bug|991898}}, {{Bug|997994}}
-# According to RFC 5280: "In conforming CA certificates, the value of the subject key identifier MUST be the value placed in the key identifier field of the authority key identifier extension (Section 4.2.1.1) of certificates issued by the subject of this certificate. Applications are not required to verify that key identifiers match when performing certification path validation." So, in mozilla::pkix we will not be checking this, but we would like to remind CAs that they are supposed to do this.
+# 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|991823}}, {{Bug|997917}}
+#* 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#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.
+#* 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 =
 While testing mozilla::pkix, we noticed the following things that we would like to consider.
 # 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 of BR #13.2.2. 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}}, {{Bug|1009110}}
+#* OneCRL will reduce our dependence on intermediate cert OCSP responses, so this is probably not worth pushing.
 # 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.
 #* Related Bugs: {{Bug|991921}}
 # Consider only giving EV treatment when the intermediate and end-entity certs in the chain have the specific EV policy OID that we are expecting; in other words, don’t give EV treatment when the intermediate certificate has the anyPolicy OID. To make this change, would need to change the CAB Forum’s EV Guidelines to also require the EV policy OID in intermediate certs (section 9.3.4 says the subordinate CA certificate may contain anyPolicy OID 2.5.29.32.0).
 #* Related Bugs: {{Bug|986156}}
+#* On consideration, this would be a big change, affecting almost all intermediates which issue EV certs. So it's probably not worth it.