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)
(a) There is no use of SHA-1 based signatures in our infrastructure related to our included root certificates and CAs subordinate to those root certificates.
(b) We use SHA-1 to sign OCSP responses, but only under a dedicated OCSP responder certificate.
(c) We use SHA-1 to sign OCSP responses, directly under a CA certificate.
(d) We use SHA-1 to sign certificates.
(e) We use SHA-1 signing in some other way.
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)
(a) id-Netscape-stepUp in Extended Key Usage extension instead of id-kp-serverAuth. Workaround to be removed in Bug #982932.
(b) DER: default value of OPTIONAL BOOLEAN explicitly encoded. Workaround to be removed in Bug #989518.
(c) DER: pathLenConstraint included when cA:False. Workaround to be removed in Bug #985025.
(d) Subject CN name information (if present) does not have a corresponding iPAddress or dNSName entry in the subjectAltName extension. Workaround to be removed in Bug #1245280.
(e) Non-PrintableString/UTF8String in DNs. Workaround to be removed in Bug #1256071.
(f) nameConstraints/subjectAlternativeName encoding mismatches. Workaround to be removed in Bug #1256073.
(g) Empty SEQUENCE in OCSP responses. Workaround to be removed in Bug #997994.
(h) keyUsage lacking keyEncipherment for certs with RSA keys. Workaround to be removed in Bug #970760; telemetry to be added in Bug #1133562.
(i) None of the above
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.
None
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)
I confirm that I understand that all issuance of certificates, which directly or transitively chain to root certificates included in Mozilla's CA Certificate Program, must conform to the procedures documented in our CP/CPS, Mozilla's CA Certificate Policy, and the CA/Browser Forum's Baseline Requirements, with the exception of certificates for which all direct or transitive issuers are technically constrained and compliant with these policies, as described in Section 9 of Mozilla's CA Certificate Inclusion Policy. This includes test certificates.
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.
There has not been a change in ownership or operation of our PKI that would necessitate updates to our CP/CPS documents or audit statements.