Confirmed users, Administrators
5,526
edits
CA:SHA1elimination: Difference between revisions
Jump to navigation
Jump to search
m
clarification
(Created page with "{{DRAFT}} = Phasing Out SHA-1 Certificates = As [https://blog.mozilla.org/security/2015/10/20/continuing-to-phase-out-sha-1-certificates/ previously communicated], CAs should...") |
m (clarification) |
||
| Line 10: | Line 10: | ||
For such situations, the following minimum requirements must be met: | For such situations, the following minimum requirements must be met: | ||
# CAs | # CAs must separate their SHA-1 certificate issuance from anything that can issue certificates for the web, using technical constraints in the intermediate issuing certificates. | ||
#* | #* To continue issuing SHA-1 certificates, the CA must use a separate intermediate certificate that has the Extended Key Usage (EKU) extension with the appropriate KeyPurposeId, and the EKU extension '''must not''' include KeyPurposeId id-kp-serverAuth and '''must not''' include KeyPurposeId anyExtendedKeyUsage. | ||
#* There are some root certificates [[CA:IncludedCAs|included in Mozilla's CA Certificate Program]] that only have the Email trust bit enabled; i.e. they do not have the Websites trust bit enabled. Issuing certificates chaining up to such root certificates are already considered technically constrained. | #* There are some root certificates [[CA:IncludedCAs|included in Mozilla's CA Certificate Program]] that only have the Email trust bit enabled; i.e. they do not have the Websites trust bit enabled. Issuing certificates chaining up to such root certificates are already considered technically constrained. | ||
# SHA-1 certificates may only be issued by a technically constrained SHA-1 SubCA that chains to an old SHA-1 (or older) root certificate. Such subCA must have as many technical constraints in the subCA's certificate validity as possible, including restrictions in key usage, extended key usage, subCA validity period and distinguished name ("path name restrictions"). | # SHA-1 certificates may only be issued by a technically constrained SHA-1 SubCA that chains to an old SHA-1 (or older) root certificate. Such subCA must have as many technical constraints in the subCA's certificate validity as possible, including restrictions in key usage, extended key usage, subCA validity period and distinguished name ("path name restrictions"). | ||
| Line 17: | Line 17: | ||
#* In practice, placing the first 160 random bits in the certificate serial number, adding the next 12 random bits to the "NotBefore time" as a count of seconds, the next 12 random bits to the "NotAfter time" as a count of seconds and inserting any remaining bits as an early element in the subject distinguished name would be the closest allowed by X.509v3 and older. | #* In practice, placing the first 160 random bits in the certificate serial number, adding the next 12 random bits to the "NotBefore time" as a count of seconds, the next 12 random bits to the "NotAfter time" as a count of seconds and inserting any remaining bits as an early element in the subject distinguished name would be the closest allowed by X.509v3 and older. | ||
#* OCSP responses for actually issued certificates should be pre-generated independent of incoming OCSP requests and include the random values as close to the beginning of the response as technically possible. Dynamically generated OCSP responses (for multiple certicates, never-issued certificates etc.) should include a random value before any request-supplied values totaling more than half the number of bits in the signing hash. | #* OCSP responses for actually issued certificates should be pre-generated independent of incoming OCSP requests and include the random values as close to the beginning of the response as technically possible. Dynamically generated OCSP responses (for multiple certicates, never-issued certificates etc.) should include a random value before any request-supplied values totaling more than half the number of bits in the signing hash. | ||
# SHA-1 certificates must be issued in a very minimal count, with short validity periods (1 to 16 months), and only to serve a specific purpose. | # SHA-1 certificates must be issued in a very minimal count, with short validity periods (1 to 16 months), and only to serve a specific purpose. | ||
#* For example for CRL signing or OCSP signing where a documented technical reason must be given for not making such signatures using dedicated certificates (for example, a specific named client implementation might fail to accept OCSP responses and/or CRL signatures not signed directly by the CA). | #* For example for CRL signing or OCSP signing where a documented technical reason must be given for not making such signatures using dedicated certificates (for example, a specific named client implementation might fail to accept OCSP responses and/or CRL signatures not signed directly by the CA). | ||
#* As an example of reducing the frequency of such signatures, CRLs might be issued with longer than usual refresh intervals for older CAs that have few remaining valid certificates and are mostly reissuing CRLs to provide trusted lists of historic revocation dates. | #* As an example of reducing the frequency of such signatures, CRLs might be issued with longer than usual refresh intervals for older CAs that have few remaining valid certificates and are mostly reissuing CRLs to provide trusted lists of historic revocation dates. | ||
# All procedures performed to comply with the above rules must be documented in the relevant CP/CPS and verified by the annual audit. | # All procedures performed to comply with the above rules must be documented in the relevant CP/CPS and verified by the annual audit. | ||