March 2016 CA Communication

 

Dear Certification Authority,

This survey requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program, by April 22, 2016.

To respond to this survey, please login to the CA Community in Salesforce, click on the 'CA Communications (Page)' tab, and select the 'March 2016 CA Communication' survey. Please enter your response by April 22, 2016.

A compiled list of CA responses to the survey action items will be automatically and immediately published by Salesforce.

In addition to responding to the action items in this survey, we request that you follow and contribute to discussions in the mozilla.dev.security.policy forum, which includes discussions about upcoming changes to Mozilla's CA Certificate Policy, questions and clarification about policy and expectations, root certificate inclusion/change requests, and certificates that are found to be non-compliant with the CA/Browser Forum's Baseline Requirements. Your contributions to the discussions will help shape the future of Mozilla's CA Certificate Program.

Participation in Mozilla's CA Certificate Program is at our sole discretion, and we will take whatever steps are necessary to keep our users safe. Nevertheless, we believe that the best approach to safeguard that security is to work with CAs as partners, to foster open and frank communication, and to be diligent in looking for ways to improve. Thank you for your cooperation in this pursuit.

Regards,

Kathleen Wilson
Mozilla CA Program Manager

ACTION #1a: As previously communicated, CAs should no longer be issuing SHA-1 certificates chaining up to root certificates included in Mozilla's CA Certificate Program. This includes TLS/SSL certificates, as well as any intermediate certificates that they chain up to. Check your systems and those of your subordinate CAs to ensure that SHA-1 based TLS/SSL certificates chaining up to your included root certificates are no longer being issued, and that any such certificates issued after 01/01/2016 have been revoked. Please enter the last date that a SHA-1 based TLS/SSL (end-entity) certificate was issued that chained up to your root certificates included in Mozilla's program (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then please enter 04/01/2016. (Required)

ACTION #1a TEXT INPUT: Use this section if you need to specify different dates according to different root certificates included in Mozilla's CA Certificate Program. Or if there is additional clarification you would like to provide.

ACTION #1b: Enter the date when all of the SHA-1 based TLS/SSL (end-entity) certificates that chain up to your root certificates included in Mozilla's CA Certificate Program will either expire or be revoked (use format MM/DD/YYYY). If your included root certificates do not have the Websites trust bit enabled or you have never issued SHA-1 TLS/SSL certificates chaining up to included root certs, then enter 04/01/2016.

As previously communicated we plan to show the “Untrusted Connection” error whenever a SHA-1 certificate is encountered in Firefox after January 1, 2017.

We recommend that you put safeguards into place that will prevent the future issuance of SHA-1 based TLS/SSL and S/MIME certificates and SHA-1 based intermediate certificates that chain up to your root certificates included in Mozilla's CA Certificate Program. (Required)

ACTION #1b TEXT INPUT: Use this section if you need to specify different dates according to different root certificates included in Mozilla's CA Certificate Program. Or if there is additional clarification you would like to provide.

ACTION #1c: It has been pointed out in the mozilla.dev.security.policy forum that a chosen-prefix attack on SHA-1 could be used to forge a certificate if a CA's private key is used to sign *anything* with SHA-1.

To what extent are SHA-1 signatures still used in the infrastructure related to the root certificates you currently have included in Mozilla's CA Certificate Program, as well as any certificates directly or transitively signed by these roots that are capable of issuance? Note: This includes both the infrastructure you directly manage as well as any contracted, delegated, or cross-certified infrastructure operated by third parties.

Please check all the boxes below that apply. (Required)

ACTION #1c TEXT INPUT: If you have selected (c), (d), or (e), please provide an explanation.

If you selected (c), there is a potential for collision attacks, especially if your OCSP responder supports the nonce extension. Please indicate whether you support the OCSP nonce extension, and any measures you have in place to prevent SHA-1 based attacks.

If you selected (d), what type of SHA-1 certificates are you issuing that chain up to your root certificates that you currently have included in Mozilla's CA Certificate Program? To what extent are SHA-1 based signatures still used by any third party who possesses a certificate capable of issuance that is directly or transitively signed by your currently included root certificates? When do you plan to stop issuing such certificates? What measures do you have in place to prevent SHA-1 based attacks?

If you selected (e), please explain how you are using SHA-1 signing, and what measures you have in place to prevent SHA-1 based attacks.

ACTION #2: Beginning with Version 2.1 of Mozilla's CA Certificate Policy, for any certificate which directly or transitively chains to the root certificates you currently have included in Mozilla's CA Certificate Program, which are capable of being used to issue new certificates, and which are not technically constrained as described in Section 9 of Mozilla's CA Certificate Inclusion Policy, you are required to provide public-facing documentation about the certificate verification requirements and annual public attestation of conformance to said requirements. This includes certificates owned by, operated by, or issued by third parties, whether or not those issuing certificates are already part of Mozilla's CA Certificate Program, if they have been cross-signed by a certificate that directly or transitively chains to your root certificate.


To facilitate this public disclosure, Mozilla is requiring that these certificates, as well as their CP/CPS and audit statements, be entered into Mozilla's CA Community in Salesforce. This includes the full PEM data of every intermediate certificate that directly or transitively chains to your included root certificates, provided that the root certificate is enabled with the Websites trust bit and the intermediate certificate is not Technically Constrained, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This also includes every variation of these certificates, in the event they were reissued, such as to change the contents of extensions or validity dates.

Please enter the date by which you plan to complete entering this data into Mozilla's CA Community in Salesforce. The date that you enter must be on or before June 30, 2016. If you have already entered your intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have unconstrained intermediate certificates, then enter 04/01/2016. (use format MM/DD/YYYY) (Required)

ACTION #3: Mozilla has implemented OneCRL to push lists of revoked intermediate certificates to the Firefox browser.

Respond with the date by which you plan to complete entry into Mozilla's CA Community in Salesforce of the data for all revoked (non-expired) certificates that were capable of being used to issue new certificates, and which directly or transitively chain to your certificate(s) included in Mozilla's CA Certificate Program and were not technically constrained as described in section 9 of Mozilla's CA Certificate Inclusion Policy. (use format MM/DD/YYYY)

The date that you enter must be on or before June 30, 2016. If you have already entered your revoked intermediate certificate data into Mozilla's CA Community in Salesforce or you do not have revoked intermediate certificates that need to be added to OneCRL, then enter 04/01/2016. (Required)

ACTION #4: In the process of implementing mozilla::pkix, a number of compatibility issues were encountered involving certificates that did not conform to the CA/Browser Forum's Baseline Requirements. To maintain interoperability, some workarounds were added to allow these malformed or improper certificates to validate successfully. However, to improve the state of the web PKI we plan to remove these workarounds, so certificates with these problems will not validate successfully.

Please check your systems to see if you are issuing certificates with any of the problems listed below. Select all of the issues in the list below that exist in certificates that chain to your root certificates included in Mozilla's CA Certificate Program that are currently valid or being issued. Update your systems to stop such issuance by June 30, 2016.

The Bug Numbers below refer to Bugzilla Bugs. (Required)

ACTION #4 TEXT INPUT: For each of the items that you selected above, please provide the number of existing certificates with that problem, the date when the last of those certificates was issued or will be issued (must be before June 30, 2016), and the date when the last of those certificates will expire.

ACTION #5: Review the root certificates that you currently have included in Mozilla's CA Certificate Program, and let us know whether any of them can now be removed or could be removed in the next year and, if so, when. For instance, if you have old root certificates that are being replaced by newer root certificates, indicate when you expect to finish migrating your customers to the new root certificates. Provide the Subject/Issuer Field, SHA-1 Fingerprint, and SHA-256 Fingerprint of each root certificate that may be removed, and the date when the root certificate may be removed.

ACTION #6: All certificates, including test certificates, that directly or transitively chain to your root certificates included in Mozilla's CA Certificate Program must comply with Mozilla's CA Certificate Policy.

Review your policies, procedures, and auditing about issuance of test certificates, what domain names may be used in test certificates, and the domain verification procedures that must be followed for test certificates. (Required)

ACTION #7: Finally, please review Mozilla's Root Transfer Policy and provide the relevant information if there has been a Change in Legal Ownership, Physical Relocation of your included root certificates, or the operation of your PKI has been transferred to a different organization resulting in new policies.