Dear Certification Authority,
This survey requests a set of actions on your behalf, as a participant in Mozilla's CA Certificate Program. If needed, you will be able to re-take this survey to update your responses by clicking on the survey link again. A compiled list of CA responses to the action items will be published.

ACTION #1: You have received this survey because you are currently the Primary Point of Contact (POC) regarding your CA's root certificates that are included in NSS. We plan to issue a SalesForce Community Plus License to each Primary POC, so CAs can input and manage some of their own CA data directly in Mozilla's CA Program instance of SalesForce. This includes the publicly-disclosed and audited subordinate CA data, as well as the revoked intermediate certificate data. Respond with one of the following. (required)

ACTION #1 Text Input: If the Primary Point of Contact (POC) for your CA has changed, please provide the new Primary POC's name, email address, and phone number. Note that this information will not be published.

ACTION #2: As you know, every CA in Mozilla's program whose root certificate(s) are enabled for the websites (SSL/TLS) trust bit must annually provide a public-facing audit statement according to the CA/Browser Forum's Baseline Requirements, in addition to the other audit statements as listed in section 11 of Mozilla's CA Certificate Inclusion Policy. Please carefully review this wiki page with your auditor: https://wiki.mozilla.org/CA:BaselineRequirements, and respond with one of the following. (required)

ACTION #2 Text Input

ACTION #3: After January 1, 2016, we plan to show the "Untrusted Connection" error whenever a SHA-1 certificate issued after that date is encountered in Firefox. And after January 1, 2017, we plan to show the “Untrusted Connection” error whenever any SHA-1 certificate is encountered in Firefox. Please review our guidance about SHA-1 certificates in our security blog, and respond with one of the following. (required)

ACTION #3 Text Input

ACTION #4: Workarounds were implemented to allow mozilla::pkix to handle the things listed here https://wiki.mozilla.org/SecurityEngineering/mozpkix-testing#Things_for_CAs_to_Fix. We plan to remove these workarounds soon, so that new certificates with these problems will fail. Please check your certificate issuance to ensure you are no longer issuing certificates with these problems. The purpose of this question is to identify interoperability problems that may arise when we make the planned code changes, so we will appreciate your diligence in investigating your certificate issuance practices and previously issued certificates before you respond to this question. Please select all of the issues in the list below that exist in currently-valid certificates that chain to your root certificates in Mozilla's program. (required)

ACTION #4 Text Input: For each of the items that you selected above, please provide the number of existing certificates with that problem, when the last of those certificates were issued, and when the last of those certificates expire.

ACTION #5: We wish to understand what support you are providing for IPv6 in the part of your infrastructure that faces relying parties (CRL and OCSP servers). One reason for this is that IPv6-only servers who want to staple, or IPv6-only clients who want to do revocation checking, will need to access the OCSP servers. Note that the Mozilla root store is used by more clients than Firefox, and clients have varying approaches to revocation. Please respond with one of the following. (required)

ACTION #5 Text Input