All,
I would like to send the next CA Communication in late April or early
May, and request CAs to respond to it within one month. For this
communication I plan to use SalesForce to email a customized survey link
to the Primary Point of Contact for each CA owner, and the responses
will be collected via SalesForce. I also plan to use SalesForce to
generate a report of the responses that I will publish.
I will greatly appreciate your thoughtful and constructive feedback on
the draft of the CA Communication below.
CAs, please do *not* send me your responses yet. Every CA will need to
respond via the survey link that will be sent to their Primary Point of
Contact.
== Begin DRAFT==
Dear Certification Authority,
This note requests a set of actions on your behalf, as a participant in
Mozilla's CA Certificate Program. Please reply by <date> with your
response to these action items. A compiled list of CA responses to the
action items will be published.
ACTION #1
You have received this email 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 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:
A) I am the Primary POC, and the SalesForce Community Plus License
should be sent to me.
B) The Primary POC for our CA has changed to... <name, email address,
phone number -- note that this personal data 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 BRs, 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.
For each root in the program, respond with one of the following:
A) Mozilla’s spreadsheet of included root certificates has the correct
link to our most recent Baseline Requirements audit statement.
B) Here is the most recent Baseline Requirements audit statement for our
certificates that are included in Mozilla’s CA program: <insert link
here>.
C) We plan to send Mozilla our current public-facing Baseline
Requirements audit statement by <insert date here and explain reason for
delay>.
D) The websites (SSL/TLS) trust bit is not enabled for our certificates
that are included in Mozilla's CA program.
E) We do not have a current Baseline Requirements audit statement for
this root certificate, because <explain reason -- If phasing out use of
the root then indicate date when the certs expire or when the root may
be removed>.
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.
Guidance about SHA-1 Certificates has been provided here:
- https://wiki.mozilla.org/CA:Problematic_Practices#SHA-1_Certificates
-
https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/
Respond with one of the following:
A) We are no longer issuing SSL SHA-1 certificates that chain up to our
roots in Mozilla's program. We never issued any SHA-1 certificates which
were valid beyond January 1, 2017.
B) We are no longer issuing SSL SHA-1 certificates that chain up to our
roots in Mozilla's program. In the past, we did issue SHA-1 certificates
which were valid beyond January 1, 2017, but they have all now been
revoked/replaced.
C) We are no longer issuing SSL SHA-1 certificates that chain up to our
roots in Mozilla's program. We have issued <number of> SSL SHA-1
certificates that are valid beyond January 1, 2017, that we have not yet
revoked/replaced, and we plan to have them revoked/replaced by <date>.
D) We currently plan to stop issuing SSL SHA-1 certificates that chain
up to our roots in Mozilla's program by <date>. We have issued <number
of> SSL SHA-1 certificates that are valid beyond January 1, 2017, that
we have not yet revoked/replaced, and we plan to have them
revoked/replaced by <date>.
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.
Respond with one of the following:
A) We have not and will not issue certificates with any of the problems
listed in the mozpkix-testing#Things_for_CAs_to_Fix wiki page.
B) We have previously issued certificates with the following problems
listed in the mozpkix-testing#Things_for_CAs_to_Fix wiki page: <list
the problems that needed to be fixed, and the number of existing
certificates with each problem>. The last of those certificates were
issued on <insert dates here, one date per problem>, and expire on
<insert dates here, one date per problem>.
ACTION #5
We wish to understand what support you are providing for IPv6
(http://www.google.com/intl/en/ipv6/statistics.html) 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.)
Respond with one of the following:
A) We support IPv6 for all our CRL and OCSP servers.
B) We support IPv6 for all OCSP servers but not CRL servers.
C) We support IPv6 for all CRL servers but not OCSP servers.
D) We partly support IPv6. <Please give details>
E) We do not yet support IPv6, but have a plan to do so <Please give
implementation dates>
F) We do not support IPv6, and have no plans to do so.
Thank you for your attention to the above listed action items. We will
appreciate your prompt response.
Additionally, we plan to update Mozilla's CA Certificate Policy soon,
and will be discussing proposed policy updates in the
mozilla.dev.security.policy forum. We encourage you to monitor the
discussions to see how the updates will impact you, and your
participation in the discussions will help shape the policy updates.
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
Module Owner of Mozilla's CA Certificates Module
=====End DRAFT========
_______________________________________________
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy
